Description

• Simplify the BlockNavigation component, moving most of the logic inside its BlockNavigationTree sub-component.

This change was initiated after a conversation that surfaced how the BlockNavigation component is currently used.

Apparently, BlockNavigation is not intended to be used directly (it's not even exported by the package), but indirectly as rendered content of the BlockNavigationDropdown's dropdown, which was normally designed as List View dropdown for the Post Editor toolbar.
This makes the "index" component very opinionated as a dropdown content. It renders a dropdown label, it only shows the blocks belonging to the currently selected hierarchy, and so on.

In time, other consumers wanted to make use of the List View, but with different opinions.
Avoiding the "index" component, they started using BlockNavigationTree directly.
The Navigation block, for example, wanted a list starting from a specific client ID.
The Persistent List View wanted all the blocks, regardless of the hierarchy, and a range of other options.

Now that we are in the process of extending the Persistent List View from the Site Editor to the Post Editor as well, we realized that the only consumer using the List View as it was originally intended (BlockNavigation called through BlockNavigationDropdown) is the Widgets Editor.
Everyone else is hacking around it by experimentally using BlockNavigationTree.

In this PR I try to acknowledge this diversity, and move all the blocks logic inside BlockNavigationTree, while maintaining the current format and extensibility.

• BlockNavigationTree is now directly responsible to retrieve the block list, the selected block (or blocks), etc.
• BlockNavigationTree has a new onlyShowCurrentHierarchy prop to limit the list to only the currently selected hierarchy (e.g. if the selected block is nested inside a group, the list will show up to that group, instead of up to the document root). This is a breaking change: this behaviour used to be the default, while now it requires a flag.
• Consumers can override the BlockNavigationTree selections by providing their own specific data through props.

Possible follow ups:

• Make BlockNavigationTree the "index" component, to better reflect how it's actually used.
• Remove BlockNavigation as we know it today. Move the leftovers (basically only the dropdown label, I think) into BlockNavigationDropdown.

How has this been tested?

Smoke test the various List View implementations:

• Post Editor (list view dropdown in the header)
• Site Editor (persistent list view in the header)
• Widgets Editor (list view dropdown in the header)
• Navigation block (block navigation in the block toolbar — make sure to select the parent block!)

Types of changes

Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• I've tested my changes with keyboard and screen readers.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.
• I've updated all React Native files affected by any refactorings/renamings in this PR (please manually search all *.native.js files for terms that need renaming or removal).