OpenUI-esque extensible widgets proposal

Nobody has claimed this yet.

I would like to propose that we re-evaluate the base widgets that Druid provides developers at the get-go to ensure that they provide sensible defaults for a good getting-started experience, while also enabling more precise thematic control in an extensible structure.

The [OpenUI project](https://open-ui.org/) is tackling similar concerns for the web platform, and I feel that there is much to learn from them with regard to creating these extensible widgets. While not every component would have an analogous form in Druid, as some are designed specifically for document navigation (such as breadcrumbs), I feel there is a large overlap between what a Druid standard component library should provide and what a web standard component library should provide. For instance, the [editors draft](https://open-ui.org/components/select) for the `` element is instructive in how we might go about providing styling capabilities without developers needing to build their own:

It's certainly a fair point to argue that perhaps Druid should not provide extensible widgets at this time, and arguments made that this should sit in a third-party library instead. My response would be that having a well-rounded set of highly customisable and extendable components would allow us to move people towards the happy path more effectively in a number of ways. Firstly, for developers just picking up Druid, it would serve as instructive learning material for how robust components should be designed. Secondly, it would allow community contributions to continually improve and fix components across all Druid apps, without the need for complex migration processes from users. I see this being especially important with regards to potential future assistive technology support -- if a button is just a customised version of Druid's platform button, then when that support is introduced, large amounts of that legwork can be adopted easily and is more likely to exist by default in the future.

I'm happy to start taking a look at this in more detail and start drawing up specifications for the components in general (the contract of which will be important if we are to improve components down the line without incurring unexpected behaviour in existing apps). I'm also very happy to pass it on to one of the maintainers if they would rather manage this instead (or if this seems out of scope for the time being).

Start by reviewing Druid's existing base widgets and the OpenUI component and Select drafts linked in the issue. Define component contracts, sensible defaults, and extensibility requirements before proposing implementation work; done would require an agreed specification rather than a single code change.

Written by the indexing model from the issue text.