Improve block registration shape to allow query options

[chriszarate]

When pairing with @brookewp during her work on data views in the editor, I realized the shape of the configuration options passed to register_remote_data_block was insufficient, e.g.:

register_remote_data_block( [
	'title' => 'My Block',
	'queries' => [
		'display' => $display_query,
		'search' => $search_query,
	],
	'query_input_overrides' => [ /* overrides * / ],
] );

Specifically, the shape of the queries property does not allow us to pass any options alongside the query. Example: We might want to pass some options alongside the search query that describe what filters or pagination options we want to enable in the corresponding data view in the block editor. Or we might want to customize the display text in various places in the block editor, like button or placeholder text.

We could cram that kind of configuration in the query itself, but it overloads the query with things that are only relevant to the block editor, and it also inhibits reusability.

Another issue with this shape is that the "display" queries and other queries are fundamentally different. The display query is required, there can only be one, and it has a distinct role for fetching and rendering content. The other queries are optional and repeatable—i.e., you can have more than one search query but this shape doesn't allow it.

Finally, this shape relegated "query input overrides" to a sibling property. This was fine, but they really only relate to the display query and are effectively an option for that query.

We can reconfigure the configuration shape to solve for all of these issues:

register_remote_data_block( [
	'title' => 'My Block',
	'render_query' => [
		'query' => $render_query,
		'input_overrides' => [ /* overrides * / ],
	],
	'selection_queries' => [
		[
			'display_name' => 'Search products',
			'query' => $search_query,
			'type' => 'search',
		],
	],
] );

This allows for repeatability where allowed, improves schema validation, and colocates options with the query they relate to. I would like feedback on names; if we prefer "render query" or another term over "display query" I will probably make additional adjustments to variable naming throughout the codebase.

[maxschmeling]

Would we want to support the render query being chosen by what selection query you use? So you could potentially have more than one render query supported by the registered block.

[chriszarate]

Would we want to support the render query being chosen by what selection query you use? So you could potentially have more than one render query supported by the registered block.

We could. I haven't really validated that idea in terms of how the block editor APIs work. Essentially you would need to store all of the information needed to execute the query in the block context.

[maxschmeling]

I could see some updates to this schema based on that down the road, but I don't think this stops us from doing that in a non-breaking way, so this looks like a good direction.