Add props for InnerBlocksTemplatePicker icon, label and instructions

[richtabor]

Is your feature request related to a problem? Please describe.
The Placeholder component (and other similar components) allow for icon, label, and instructions props, for an "informed" component. InnerBlocksTemplatePicker does not allow for this, as each of the corresponding props are established within the component itself.

It would be useful for blocks to pass custom icon, label, and instructions props, so the template picker can be relative to the current block.

For example, we recently adapted this functionality within the CoBlocks Form block. It works great, but the template placeholder is not relative to the Form block. Without the block icon within the toolbar, you wouldn't know this was a Form block template/pattern selector.

Describe the solution you'd like

If props were available, I would:

1. Use the block's icon, in place of the layout icon currently provided
2. Change "Choose layout" to "Choose form layout"
3. Update the instructions to reference form templates.

These would all make the block's placeholder state much more relative, providing context to the pattern selector.

Describe alternatives you've considered
There are none.

[gziolo]

I have a patch ready in #18283 that addresses all the issues you mentioned. I also struggled with the default proposal which couldn't be customized for other block types.

The same PR renames InnerBlocksTemplatePicker to BlockPatternPicker. We still haven't decided whether it's going to be exposed as part of the public API but this PR does it and marks it as experimental.

[gziolo]

@richtabor, thanks for sharing your use case. I see that you are using experimental props for InnerBlocks:
https://github.com/godaddy-wordpress/coblocks/blob/520869d400807659f57479107461dca1b48fdb33/src/blocks/form/edit.js#L387-L400

I propose in #18283 we remove all those experimental features in favor of standalone BlockPatternPicker which might even stay internal if we find a nice way to abstract Patterns API in a way where it's all handled by BlockEdit based on the registered patterns. This should make it easier to maintain all those predefined templates. I'm wondering if you have some thoughts on how this can be handled so CoBlocks could continue to work with the previous versions of Gutenberg. Do you think it's possible to implement some sort of feature detection?