chore: Framework-ify SubconsciousCore

[jsantell]

...into common components for extending with private features, and debrand existing iOS/macOS targets.

Changes

• Created a SubconsciousCore shared framework, containing core models, components and services needed for both public and private components. iOS and Mac targets depend on this framework.
  • All swift files have been added to this core, with the exception of SubconsciousApp.swift as the "public entry point". In time, core may contain protocols, where individual targets bring their own implementation. More maintenance will be needed to align with this structure e.g. Config is a structure in the core framework, but values are provided by target-level.
  • Some classes that will have different implementations (e.g. Config) should be overridable by target
• Renamed current Subconscious targets to Unconscious/com.subconscious.Unconscious.
• Added public visibility to top-level SubconsciousCore items to be accessible outside of the framework

Futures

This is more of a proposal than a change request. Structuring internals into a shareable framework allows us to extend with private functionality in one of two ways:

• Adding a new target to the existing project that pulls in a private framework. Ease of a single workspace, but difficulties arise when wanting private framework to also use the shared framework.
• Creating a new SubconsciousPrivate workspace that pulls in SubconsciousCore, layering on its own implementations (e.g. of top level views, configurations, and protocol implementations). A bit duplicated effort in build configurations, but maybe for the best.

There's not a lot yet to add to a private framework, but we can start developing patterns to support this (e.g. separation of definitions from implementations) as we implement these features.

[gordonbrander]

@jsantell When I check out this branch, I am missing a few files. Did something not get checked in? Or perhaps is there a step I need to take in Xcode?

[gordonbrander]

While learning about frameworks, I discovered there is also the concept of a "workspace" which can hold an app and multiple frameworks. I've drafted a PR with a workspace and an empty SubconsciousCore framework #887

@jsantell do you know anything about the pros/cons of this approach vs the approach in this PR?

[jsantell]

@jsantell When I check out this branch, I am missing a few files. Did something not get checked in? Or perhaps is there a step I need to take in Xcode?

These maybe need to be built -- products are generated build artifacts -- I'll take a look!

While learning about frameworks, I discovered there is also the concept of a "workspace" which can hold an app and multiple frameworks. I've drafted a PR with a workspace and an empty SubconsciousCore framework #887

@jsantell do you know anything about the pros/cons of this approach vs the approach in this PR?

I think we already are using a workspace, and IIRC is an evolution of a project, that can contain multiple projects. All projects (and workspaces) can contain multiple apps and frameworks (both targets). What verbiage!

That is to say, unless we're importing another project (or maybe workspace), e.g. proprietary components, there's not much difference between project/workspace, and is orthogonal to frameworkifying the underlying components. The benefits of bundling Subconscious as a framework mean it's a single artifact that can be consumed by multiple targets and schemes e.g. across tests, "unconscious", branded app, desktop/Mac versions (multiplied by dev/prod schemes), rather than having individual source files be members of each scheme leading to duplicates and missing sources (both discovered during this frameworkifying process), as well as potentially being an opaque dependency for e.g. proprietary components