[Autocomplete] Refactor useAutocomplete to use Base UI building blocks

[michaldudak]

The useAutocomplete hook was created before Base UI existed and has code patterns different from the rest of the hooks in the library. Additionally, it does not use the lower-level building blocks from Base UI (like useList) but implements its whole functionality by itself. Reusing the same building blocks as other components could help us reduce the overall bundle size and have feature parity with the Select (where applicable).
There are a number of issues reported that could be solved by replacing the implementation.

Areas of improvement:

• Use useList instead of reimplementing keyboard navigation
• Convert the code and tests to TypeScript
• Do not set any classes (it's a responsibility of a component, not a hook)
• Accept external props in get*Props functions
• Implement a reducer to handle state and expose its dispatch function to allow programmatic control
• Revise prop naming (like freeSolo)

Issues that could be solved along the way:

• [Autocomplete] Support values other than raw options material-ui#23708
• [Autocomplete] Differentiate hover & keyboard states material-ui#23916
• [Autocomplete] Update to ARIA 1.2 material-ui#25365
• [Autocomplete] getOptionLabel callback is getting the value instead of option object material-ui#31192
• [Autocomplete] The onHighlightChange event is triggered by child elements of the list item material-ui#31383
• [Autocomplete] ArrowUp must be pressed twice to bypass disabled items above material-ui#32280
• [Autocomplete] - resetInput when value reference changes material-ui#35533
• [Autocomplete] Add onScrollToBottom prop material-ui#35653
• [Autocomplete] Type error of getInputProps() material-ui#36552
• [Autocomplete] allow clearing the value also programmatically material-ui#37738

Since this will likely be a breaking change, we should leave the current version intact (but deprecate it and remove it in the future).

[sai6855]

Since useList is going to use in Select, Menu, Autocomplete (In future). does it makes sense to add Infinite scroll feature in useList itself (as it's one of most requested feature)? Once it is implemented in useList, Autocomplete just need to pass necessary props to make it working.

[michaldudak]

I don't think components other than Autocomplete would make use of infinite scroll, so we need to be careful not to include features that won't be used but will increase the component size. I think we can add an event to the List fired when scroll is near the bottom.

[marcpachecog]

@michaldudak Infinite scrolling inside a list is in fact a very common feature rather than not, I have it implemented on my own by using the Intersection Observer. So it make sense to also add it to the List as you mentioned.

[mj12albert]

I've opened an issue to organize the scope of Autocomplete for material-next: mui/material-ui#39963

I think at a minimum we can convert to TS