Language switcher: connect to prefs & clean up some code

It may be easiest to review each commit individually, since they're fairly distinct:

Second commit - new feature:
* Add "Set as Default" menu item to status bar language switcher -- adds a permanent file extension mapping to preferences, based on the current file's path-specific language override (if any) and its file extension.

First commit - cleanups:
* Make LanguageManager the official public API that is used to set per-file overrides, rather than proxying through Document objects - remove `Document.setLanguageOverride()`
* Clear path overrides when switching projects, so it's more obvious to users it's not something that gets persisted across sessions
* Simplify how JS Code Hints listen for language updates: remove dependency on `"currentDocumentLanguageChanged"` event; remove unneeded extra 'if' tests

Third commit:
* Improve "Set as Default" menu item -- gray it out when the current file has no path-specific override (i.e., when the current language already is the default for the current filetype)
* Extend DropdownButton / DropdownEventHandler to support disabled items.
* In the process, clean up dropdown keyboard navigation substantially -- fixing #8433.

~~For clarity, I'd ideally like the "Set as Default" menu item to be grayed out when there is no path-specific override on the current file (i.e., when the current language already _is_ the default for the current filetype)... but disabled items aren't a think in DropdownButton yet and I will need to do some cleanup there to get it working -- so I wanted to post this initial for review first.~~ _(this is now implemented)_
I guess that's an interesting architecture philosophy question here (CC @dangoor :-) ...should prefs be considered an encapsulated, private detail of a module (hidden behind programmatic APIs)?  Or are they a public API in themselves, since any user can touch them too?

Personally, I'd lean toward the latter.  Preferences have to be treated much like a frozen API, because we document them publicly and we need backwards compatibility with existing user .json files.  Also, prefs definers need to listen to changes in the underlying prefs since users can edit the file at any time -- and making programmatic changes all go through an API might subtly encourage forgetting to handle the external-change case properly.