Trac ticket: https://core.trac.wordpress.org/ticket/52920

Related to WordPress/gutenberg#28701.

Required for WordPress/gutenberg#29969 - new REST API endpoint for the editor settings.

We are approaching the day where new screens with the block editor get included in WordPress core. It looks like there are several WordPress hooks defined on the server that depends on $post object that isn’t present on the edit site, edit widgets, or edit navigation screens. It feels like we should deprecate existing filters and create replacements that are going to be context-aware.

It's a work in progress.

Changes included so far:

• new method get_default_block_categories were introduced to make is possible to share default block categories
• new method get_allowed_block_types was introduced to handle filters depending on the editor type
• most of the settings that are defined on the client in the block editor package in https://github.com/WordPress/gutenberg/blob/trunk/packages/block-editor/src/store/defaults.js are already exposed from the new get_default_block_editor_settings method
• another method get_block_editor_settings got introduced to ensure that editor settings can be filtered depending on the editor type
• the logic that preloads common data used with the block editor by processing an array of REST API paths is now abstracted in block_editor_rest_api_preload method

All existing filters that depend on $post object get deprecated with apply_filters_deprecated as suggested by @jeremyfelt:

• allowed_block_types
• block_categories
• block_editor_preload_paths
• block_editor_settings

New filters are introduced that are context-aware:

• allowed_block_types_all
• allowed_block_types_{$editor_name}
• block_categories_all
• block_editor_rest_api_preload_paths
• block_editor_preload_paths_{$editor_name}
• block_editor_settings_all
• block_editor_settings_{$editor_name}

In the case where there are two filters for a general use case that covers any editor type and a specific one, I followed https://core.trac.wordpress.org/ticket/46187 and the implementation for render_block + render_block_{$block_name}. @johnbillion shared more examples in https://core.trac.wordpress.org/ticket/46187#comment:9:
Detailed filters per editor type are on hold upon feedback received from @youknowriad, @chrisvanpatten, and @TimothyBJacobs . We want to make it more flexible and it might end up with a special object that holds context.

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.