Removing AbstractUI requirement from Cores and the SDK

[Arlodotexe]

Discussed in https://github.com/Arlodotexe/strix-music/discussions/144

^{Originally posted by **Arlodotexe** June 2, 2022} # Background When designing the core interfaces, one of the questions that we had to ask ourselves is "How will cores provide a generic settings UI to the user in a way that doesn't tie us to a UI framework?" Ultimately, this led to the creation of AbstractUI, a set of models that represented simple UI elements, and could be abstracted as pure data (to account for out of process cores). # Where we are now AbstractUI is used in _all_ current cores as creating an AbstractConfigPanel is a requirement to implement `ICore`. Headless cores have always been at the back of my mind during the development of the SDK. Though we've never actually instantiated a core headlessly, it's something I've been creeping towards while evolving the architecture. While writing documentation for creating a core the other day, in order to make headless cores a standard thing, I made it a suggestion for all cores to expose a configuration object (usually the actual core settings) in the constructor. Again, we hadn't needed this, but I knew we were going to, especially if we published in a nuget package. Then it dawned on me: The AbstractUI panel only serves to set these settings internally in a core. Why not just set them directly, before the core is ever instantiated? # Proposed changes With the above in mind, my proposal is to **remove `ICore.AbstractConfigPanel` and all dependency on AbstractUI from the SDK**. There's a few clear benefits to this: - All cores work headless by default - We can remove the weirdness around listening for the `CoreState.NeedsConfiguration` state to know if you should show the config panel. - Creating a core is much simpler. You don't need to create a settings UI - you directly expose the settings and maybe some setup helpers. - Configuring a core can still be done with AbstractUI, it just wouldn't be embedded into the core. This still allows us to do remote cores. - Not being bound to AbstractUI limitations means you can create a significantly nicer setup UI. - Having an AbstractUI renderer won't be a requirement to _use_ a core. And also some cons: - Unless you can find existing AbstractUI components to do it, you have to create the setup UI yourself. - The architectural details on how you might do login/setup to get valid setting values before instantiating a core don't exist yet - we need to figure out what the best approach is.

[Arlodotexe]

Doing this will also allow us to initialize all cores in parallel without being interrupted by multiple configuration requests.