feat: nested collection support

[nwidynski]

Closes #7277 (comment)

As discussed, this change focuses only on the bare minimum to get nested collections to work.

✅ Pull Request Checklist:

• Included link to corresponding React Spectrum GitHub Issue.
• Added/updated unit tests and storybook for this change (for new code or code which already has tests).
• Filled out test instructions.
• Updated documentation (if it already exists for this component).
• Looked at the Accessibility Practices for this feature - Aria Practices

📝 Test Instructions:

🧢 Your Project:

[nwidynski]

Not sure, why were we casting here?

[LFDanLu]

@nwidynski Heya, sorry about the delay, we were pretty busy with getting the release out. As mentioned in #7277 (comment) we are leaning towards supporting inputs in Gridlist first via something like #7360, which you had already noted doesn't solve the typeahead collision problem.

However, instead of making typeahead disable-able via a prop, we tossed around an idea of perhaps just doing some detection in the useTypeselect hook to see if the user was typing in an input and simply early return at that point. Any thoughts on that approach?

[nwidynski]

@LFDanLu No worries about the timeline 👍

I suppose you were exploring that idea to lighten the burden on the developer? If so, I don't see why these necessarily have to exclude each other. Preventing type select only when focus is currently on an input, will still cause issues with nested collections. Was there other reasoning for prohibiting the exposure of disallowTypeAhead?

As mentioned (see comment), this PR focuses only on the essentials of supporting nested collections and can be seen as independent of #7360. Only the Document key and type select are things we have to fix upstream to implement our use-case. Everything else we proposed, including #7360, we can temporarily implement ourselves through a custom virtualizer.

On that note, any feedback from the team on #7376?

[LFDanLu]

There was also a concern about exposing disallowTypeAhead since it may not be clear to a user when/when not to disable it. That being said, at a glance it doesn't appear in the grid spec so maybe not as core of an interaction pattern as previously thought. No feedback on #7376 just yet, I hope to take a look at it soon as soon as I get to a good place with the SearchableMenu/Autocomplete support myself.