TT | 3471 | "Introduce allow-list and disallow-list for blocks."

This is meant to be treated as a request for comments.

I haven't spent a lot of time trying to document everything yet. I did spend some time writing type declarations in JSDoc until my comments ended up becoming larger than the actual implementation itself to which I started to question the value at that point. I can include them if it makes sense to do so.

The general idea behind this work is that there is a desire to allow the Gutenberg Block Editor to restrict the block types it offers in various contexts it is presented in to the customer.

The changes found here should, in theory, only impact the blocks presented in the block picker, and not affect the blocks displayed within the editor if someone were to manually modify the markup.

The "requirements" that I thought seemed reasonable to me would be:

+ If you pass in neither an allow list nor a disallow list, then proceed by using all core blocks.
+ If you pass in an allow list, and not a disallow list, then proceed by only including what is in the allow list from the entire set of core blocks.
+ If you pass in a disallow list, and not an allow list, then proceed by including the entire set of core blocks sans the blocks in the disallow list.
+ If you pass in both an allow and disallow list, then proceed by removing blocks named in the disallow list first and then only keeping the blocks named in the allow list from the resulting set of the disallow list. However, this use case isn't realistic in my opinion. The consumer should only provide an allow or disallow list whichever is more convenient for the context. An allow list is preferred when the amount of blocks we'd like to present to the customer is small. The disallow list is preferred when the amount of blocks we'd like to present is large.
+ If you pass in an allow list that does not include `core/paragraph`, as that appears to be the minimum needed block, then ensure it's included in the allow list.
+ If you pass in a disallow list that includes `core/paragraph`, then ensure it is removed from the disallow list.

I made an assumption that `core/paragraph` was a require block at minimum because when the disallow list didn't allow it to be registered, the application would crash at runtime. So I made a "needed blocks" list to make vital blocks be ignored from the allow or disallow lists.

I can add tests that reflect the requirements defined above. I did look for existing tests for this module and wasn't able to find them, but I may just not be understanding the general testing strategy.

+ `packages/block-library/src/common.js` - I added a new `common` module to be shared between the entry point module for `web` and for `native`. Otherwise, I would likely have to add a duplicate implementation of the newly introduced `registerCoreBlocksByName` function, and that causes IDE warnings about redundancy.
+ `packages/block-library/src/index.js` - I exposed an entry point to register a subset of the complete collection of Gutenberg Editor Core Blocks called `registerCoreBlocksByName`. It is intended to allow registration of a subset of blocks by their `name` defined in their respective `block.json` declarations. I gave some thought into whether or not more than the `name` field would be convenient if we'd like to overwrite other fields from the block declarations when registering, but I kept it simple for the sake of getting the general idea of the implementation across. That can always be a minor enhancement.
+ `packages/block-library/src/index.native.js` - I organized the general set of core blocks to be returned from a `__experimentalGetCoreBlocks` to keep it homogenous with the `web` entry point especially since `__experimentalGetCoreBlocks` and `registerCoreBlocks` are transitive dependencies of the newly added `registerCoreBlocksByName` function. I also exposed an entry point to register a subset of the complete collection of Gutenberg Editor Core Blocks called `registerCoreBlocksByName` to keep it homogenous with the `web` implementation explained above.
+ `packages/react-native-editor/src/index.js` - I updated the entry point of the `react-native-editor` package to accept two new props passed in from the native bridge within the WordPress Android or iOS apps called `acceptBlocks` and `rejectBlocks` to be treated as an "allow" and "disallow" list. The naming was difficult so I can rename it if something else may make more sense from the perspective of the consuming application. These two new props are passed to the new registration entry point, i.e., `registerCoreBlocksByName`.

[3471](wordpress-mobile#3471)