Remove combobox autocomplete modes

[jattasNI]

Pull Request

🤨 Rationale

Fixes #2347. In that issue we decided to deprecate the combobox autocomplete modes both and inline because they are too aggressive about filtering out options that should match what the user typed but don't match what the component autocompleted. Short term, clients can either use autocomplete="list" or switch to a filterable nimble-select. Long term we may change combobox autocomplete to behave more like select.

👩‍💻 Implementation

1. Created a type for the autocomplete attribute in Nimble to replace the one from FAST
2. Deleted code from nimble-components that was only relevant to those modes
3. Angular and Blazor: trivial test and example app updates, plus updating the Blazor type that corresponds to the nimble-components one.
4. Storybook: remove docs and tests that reference those modes

In this SLE PR I'm updating places that used "both" to now use "list".

🧪 Testing

• Updated tests that didn't care about the mode to use a mode that's still supported.
• Deleted tests that no longer apply
• the forked "foundation" test still uses the FAST type since it's testing FAST code that uses that type. There was one place where the test is relying on the Nimble element so it produced a type mismatch, but by luck that code was using modes that are still supported in both places, so some type tweaks allowed it to continue working.

✅ Checklist

• I have updated the project documentation to reflect my changes or determined no changes are needed.

[jattasNI]

This change causes the test in this describe block to fail both with and without the other changes in this PR. I haven't yet investigated why: interactively it behaves correctly to scroll the selected item into view when autocomplete="list".

[atmgrifter00]

So, the issue is that when you change to list the items in the dropdown are limited to what has been typed in the input, whereas before they were not. Changing this to none (or simply removing this attribute), in addition to a change needed in the focusAndScrollOptionIntoView implementation (see this commit).

[atmgrifter00]

@jattasNI and @rajsitem the code I've removed here was partially responsible for keeping a test from passing. Essentially document.activeElement had not been updated to something contained within the Combobox. While I can't say I confidently know why that is, the removed logic still seems wholly unnecessary. I see no reason why we have to explicitly place focus on the input in the template when scrolling the selected option into view, nor a reason to gate this on the currently focused element already being within the Combobox. This method should just be concerned with scrolling the current selected item into view.