feat: remove theme fragment minimum and allow "app" fragments

[Westbrook]

Description

• removes the fragment minimum before a "theme" is applied to sp-theme
• moves to an async rendering pattern to prevent multiple renders as various fragments are loaded
• adds support for an app fragment so that consuming application can hang local extensions of the Spectrum CSS Custom Properties API on the sp-theme element

Questions:

• This approach does not support for more than one app fragment, is that OK?
• This approach does not support removing the app fragment, is that OK?
• @stanvladut pointed out how his team was previously overload fragments to achieve a similar goal, should we prevent that in some way?
• Is it OK to allow "partial" themes or should we ensure one of each fragment type via a more rigorous check?
• Are there edge/use cases that I've not thought of here?

Related Issue

fixes #1496

Motivation and Context

Easier customization of applications consuming Spectrum Web Component and associated styling APIs

How Has This Been Tested?

• updated existing tests
• added new tests
• found acceptable VRT failures and adopted them (when we agreed that they were acceptable)

Types of changes

• Refactor
• New feature (non-breaking change which adds functionality)
• Possibly Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• I have signed the Adobe Open Source CLA.
• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[stanvladut]

Exepting the minor comment I posted, the changes look good, great job. Thanks for working on this and proposing a solution so fast!

My opinion on some of the questions posted:

1. Generally speaking, I think it's enough (at least for my team) to only have one app fragment. We can compute our app styles locally, depending on color, scale or other factors and register it when ready.
2. I cannot think of a scenario where we would want that, as long as we can change the styles for the app fragment. Keeping in mind that the local app styles might also depend on color or scale, we might want to recompute the app styles and update them, but not remove.

[stanvladut]

Shouldn't this be of type FragmentName, as it can have values other than 'color' | 'scale' | 'core' | 'app'?

[Westbrook]

Good call. Even my own typescript alludes me more than I'd like! 🙈

[stanvladut]

Great work! 💯

[stanvladut]

Great work!