This commit introduces a rough prototype of the Settings UI as the
`TerminalSettingsEditor`. This project was added to OpenConsole.sln and
deploys as a standalone app. Some databinding is configured to a fake
TerminalSettingsModel (located in the ObjectModel folder).

This commit will start the settings UI feature branch, which will
receive a full review on merge-back into main.

References #6720 - Settings UI Spec and Design
References #1564 - Settings UI Feature/Epic

This PR's only purpose is to convert the TSE project into a DLL while getting rid of unnecessary files in the meantime, namely the `App.*` files and moving its `ResourceDictionary` into a file called `CommonResources.xaml`.

In the process, I needed to move all the `Model` classes under `Editor` since it would have been a huge pain to try to add a Model dll alongside the Editor dll. I figured it also wouldn't matter too much since we'll be deleting the `Model` namespace in favor of using the incoming TSM.

While this doesn't contain any code of putting the Settings UI in a tab, I figured it would be nice to push this particular part as its own standalone PR.

This commit introduces a rough prototype of the Settings UI as the
`TerminalSettingsEditor`. This project was added to OpenConsole.sln and
deploys as a standalone app. Some databinding is configured to a fake
TerminalSettingsModel (located in the ObjectModel folder).

This commit will start the settings UI feature branch, which will
receive a full review on merge-back into main.

References #6720 - Settings UI Spec and Design
References #1564 - Settings UI Feature/Epic

This PR's only purpose is to convert the TSE project into a DLL while getting rid of unnecessary files in the meantime, namely the `App.*` files and moving its `ResourceDictionary` into a file called `CommonResources.xaml`.

In the process, I needed to move all the `Model` classes under `Editor` since it would have been a huge pain to try to add a Model dll alongside the Editor dll. I figured it also wouldn't matter too much since we'll be deleting the `Model` namespace in favor of using the incoming TSM.

While this doesn't contain any code of putting the Settings UI in a tab, I figured it would be nice to push this particular part as its own standalone PR.

…nto feature/settings-ui

…7802)

This PR's goal was to add an option to the `OpenSettings` keybinding to open the Settings UI in a tab. In order to implement that, a couple of changes had to be made to `Tab`, specifically:

- Introduce a tab interface named `ITab`
- Create/Rename two new Tab classes that implement `ITab` called `SettingsTab` and `TerminalTab` 

I've also put some `TODOs` that I wanted to get some thoughts on - I'll make a follow up PR but perhaps they can be revisited when we flesh out the Settings UI more.
- Does a Settings UI tab shutdown need to do anything special for cleanup?
- Does a Settings UI tab need to have `GetActiveTitle`? Maybe depending on which page in the UI is open?
- Technically, I can't focus a `Grid` control, so I'll need to figure out what to `Focus` when the tab is selected.
- The Settings UI tab doesn't have a `TermControl`, so once focus is moved to that tab, users won't be able to `nextTab/prevTab` out of it (along with all other keybindings).

References #1564, #5915

<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
Moved all strings into resources file for localization.

<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> 
## References
#1564 - Epic

<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [ ] Closes #xxx
* [x] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [ ] Schema updated.
* [x] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx

<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments

<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed

Added save and reset buttons.
Added warning message for unsaved settings.

![save/reset buttons and warning](https://user-images.githubusercontent.com/48369326/96289952-b6221800-0f9a-11eb-9d98-bd62c17aca19.png)

## References
#1564 - Settings UI Epic

This import is required to make localized resources work.

This PR's main goal was to get rid of all our ObjectModel references and replace them with references to TSM. 

There's a lot of places in the SUI where I wasn't able to easily drop in the TSM. Usually those settings types aren't as simple as a boolean, so they'll require some templating and finessing. For those settings, I've either commented them out for now or attempted to replace them. Here's a TLDR of what I've done in this PR.

- Since `MainPage` is the entry point, it gets a `CascadiaSettings` object to hold on to, and that's the settings object the rest of the pages will bind to.
- Deleted everything inside of `ObjectModel` along with their references.
- Replaced the ObjectModel references in the `.xaml` files with a reference to the settings object obtained in `MainPage`
- Commented out a couple of settings here and there that might need converters and/or templating.
- Attempted to write out most of the templating and data binding code for `ColorSchemes.xaml`

<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
Fixes the last bit of missing localization for the settings UI

<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> 
## References

<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [ ] Closes #xxx
* [ ] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [ ] Schema updated.
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx

<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments

<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed

<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
Updated icons for:
- Startup
- Appearance
- Color schemes (moved the palette icon from Appearance to here)
- Profiles

![image](https://user-images.githubusercontent.com/48369326/96916583-97b99200-145c-11eb-9301-df7b824fb1da.png)

<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> 
## References

<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [ ] Closes #xxx
* [ ] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [ ] Schema updated.
* [x] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx

<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments

<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed

This PR fleshes out the Settings UI's ColorSchemes page so that it's
able to display all your defined color schemes. It'll allow the user to
modify all the colors of the scheme through either a color picker or
entering a hex color in the TextBoxes. If the user enters an invalid hex
code, the TextBox will automatically revert back to the original hex.
Since we haven't hooked up the save button just yet, making any changes
to a color scheme will modify the color scheme only for the currently
open Terminal instance. 

References #1564

When I did the polishing I forgot to do the Advanced page under profiles. I fixed that here.

<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
Removed the following from the navigation menu:
- Search bar
- Home page
- Keyboard page

Changed landing page to Launch page

![image](https://user-images.githubusercontent.com/48369326/97476068-3afe2180-190b-11eb-9c9b-9b0c07a6974c.png)

<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> 
## References
#1564 

<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [ ] Closes #xxx
* [ ] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [ ] Schema updated.
* [x] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx

<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments

<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed

This PR will make the "Open JSON file" navigation view item in the Settings UI will open the user's settings file. Normally, `NavigationViewItems` raise their parent's `ItemInvoked` handler, but when a `NavViewItem` is in the `NavigationView.PaneFooter`, it doesn't do that. So, we have to hook up `OpenJson`'s `Tapped` and `KeyDown` handler to detect both a tap event and the enter keydown events.

References #1564

<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
Fixed the resizing bug where long text buttons get cut off, hid the unsaved changes warning, and changed "save" to "apply"

![MicrosoftTeams-image (1)](https://user-images.githubusercontent.com/48369326/97494176-2f1e5980-1923-11eb-8980-604bd5a067e5.png)

![image](https://user-images.githubusercontent.com/48369326/97494207-3a718500-1923-11eb-9409-7a95ecb50536.png)

<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> 
## References
#1564 

<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [ ] Closes #xxx
* [ ] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [ ] Schema updated.
* [x] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx

<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments

<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed

This fixes the bug where on a Color Scheme change, a portion of the
color pickers will be set to the correct color, but the other portion of
the color pickers will be set to the same colors that the first portion
was set to. It looks like performing a `Clear` and `Append` confuses the
Color Pickers when they raise their `ColorChanged` events in response.
Avoiding the `Clear` and `Append` by just changing the `Color` property
allows the Color Pickers to keep their existing data bound object and
only react to their Color property changing instead of having to deal
with the whole object being swept out from under them and being given a
new one.

<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request
The logic of the showTabsInTitlebar setting was backwards in the settings UI.

<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> 
## References

<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [ ] Closes #xxx
* [ ] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [ ] Schema updated.
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx

<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments

<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed

`TerminalTab` and `SettingsTab` share some implementation details. The
close submenu introduced in #7728 is a good example of functionality
that is consistent across all tabs. This PR transforms `ITab` from an
interface, into an [unsealed runtime class] to de-duplicate some
functionality. Most of the logic from `SettingsTab` was moved there
because I expect the default behavior of a tab to resemble the
`SettingsTab` over a `TerminalTab`.

## References
Verified that Close submenu work was transferred over (#7728, #7961, #8010).

## Validation Steps Performed
Check close submenu on first/last tab when multiple tabs are open.

Closes #7969

[unsealed runtime class]: https://docs.microsoft.com/en-us/uwp/midl-3/intro#base-classes

<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? -->
## Summary of the Pull Request

![image](https://user-images.githubusercontent.com/48369326/97521600-22b5f300-195b-11eb-8890-7f489a4be4ab.png)


<!-- Other than the issue solved, is this relevant to any other issues/existing PRs? --> 
## References

<!-- Please review the items on the PR checklist before submitting-->
## PR Checklist
* [ ] Closes #xxx
* [ ] CLA signed. If not, go over [here](https://cla.opensource.microsoft.com/microsoft/Terminal) and sign the CLA
* [ ] Tests added/passed
* [ ] Documentation updated. If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/terminal) and link it here: #xxx
* [ ] Schema updated.
* [ ] I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx

<!-- Provide a more detailed description of the PR, other things fixed or any additional comments/features here -->
## Detailed Description of the Pull Request / Additional comments

<!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well -->
## Validation Steps Performed

## Summary of the Pull Request
Since we've started working on the Settings UI, a few settings have been added on `main`. This adds those missing settings over. 

## References
Missing settings include...
- #7364: `disableAnimations`
- #7873: `launchMode` `focus` and `maximizedFocus`
- #7793: `bellStyle`

## Validation Steps Performed
Verified that those settings appear properly in the Settings UI.

## Summary of the Pull Request

This removes "Globals" files, a relic from the hackathon. We decided to split this up into all the other pages, and forgot to remove this at some point.

## References
#1564 - Settings UI Epic

## Validation Steps Performed
Deployed and it worked fine (after going to settings ui page)

Create a header for Profiles inside the nav, where profiles can populate.

This PR fixes a crash where looping through a NavView's items would attempt to grab a `NavigationViewItemHeader`'s null tag and crash. This for-loop wasn't needed anyway since we've gotten rid of the home page.

This PR's goal was to expose the String to Enum mappings we have in JsonUtils and to bind a group of Radio buttons to that setting and its possible enum values. To allow the Radio button groups to be data bound to, I created an EnumEntry class in TSE that'll take a string to represent your enum value name and an IInspectable to associate that name with an enum value. There's also macros that will initialize the necessary properties for a setting whose type is an enum. With these macros, you'll be able to bind to a collection of enum values and to the enum setting itself.

References #1564

"Reset" is confusing because it could mean resetting to defaults.

## Summary of the Pull Request
This binds the "Default Profile" global setting in the Settings UI.

The combo box needs a list of string values, so I convert the list of profiles into an observable list of string values for the combo box. We specifically try to use the index to avoid running into the problem of two profiles potentially having the same name.

## References
#1564 - Epic for Settings UI

## Validation Steps Performed
See attached gif. This tests...
- the list of profiles is shown
- the starting profile is selected
- selecting a new profile changes the default profile

![DefaultProfileBinding](https://user-images.githubusercontent.com/11050425/97920203-f8bf5080-1d0d-11eb-80f6-1253ce8bb455.gif)

Unfortunately, to my knowledge, we're not able to have a mix of
XAML-declared NavigationViewItems alongside a templated set of
NavViewItems. So, in order to place the Profiles in the NavView, I
created the controls in code-behind and appended them to the end of the
NavView. Then each Profile navigates to the Profiles page and the
OnNavigatedTo handler takes care of initializing the page with the given
Profile. Also as part of showing Profile icons, I moved the
IconPathConverter to TSM.

A couple things not yet implemented in this PR (will note them on the
board):
- Not all Profile settings are fully hooked up yet (all radio buttons,
  checkboxes, and all settings in Advanced pivot are hooked up)
- If a name or icon is changed through the Profiles page, it won't
  update in the NavView. Removing a Profile won't update the NavView.

![profilesnav](https://user-images.githubusercontent.com/57155886/98171352-74530600-1ea4-11eb-900f-fc17634eacb5.gif)

References #1564

## Summary of the Pull Request
Navigating to pages in the Settings UI now passes in a state of the
relevant settings at the time of navigation. This helps scope each page
to its relevant settings. For example, a `Profile` page now has access
to the relevant `Profile` and color schemes. This allows the page to see
all of the relevant profile settings, and (soon) display the possible
color schemes to choose from.

If a developer wants a page to have access to more settings or context,
they can now add it to the pertinent NavigationState runtimeclass and
pass it to the page in `MainPage` (most likely `Navigate()`).

## References
#1564 - Settings UI

## Additional Comments
- Pages are not constructed when you navigate to them. Thus, we cannot
  track the state by passing it into the constructor of a `Page`.
- This PR also does a little bit of polish in `MainPage.cpp`'s
  navigation functions such as defining tags at the top of the file and
  simplifying/de-static-ifying `Navigate()`.
- This also fixes a bug where loading the settings page would always
  take you to the first item.

## Validation Steps Performed
Visited every page on the Settings UI.

## Summary of the Pull Request
Now that the IconConverter was moved to TSM, SUI has access to it. This uses the IconConverter to include an icon in the Default Profile dropdown.

![demo](https://user-images.githubusercontent.com/11050425/98307553-d716d100-1f7a-11eb-9c94-13d88a6df88b.gif)

## References
#1564 - Settings UI

## Summary of the Pull Request
This PR performs a wholistic polish on the Settings UI by doing the following:
- Use NavigationView's header to display which page you are currently on (and style it appropriately)
- Remove back button (deemed unnecessary)
- Rely more heavily on CommonResources.xaml for consistent styling
- Replace `profile.schemes` and `profile.backgroundImageAlignment` with ComboBox controls (still not bound)
- Replace Profile-->Appearance page grid layout with a stack
  - I know we desire a reflowable 2-column layout. But that's just too much work for now. I'm focusing on getting the Settings UI in a mergeable/shippable state.
- General code cleanup (particular focus on .xaml files)

Rather than posting many photos of all the changes, I suggest that you (the reviewer) just download and play with the branch. We shouldn't have any more weird resize scenarios.

## References
#1564 - Settings UI

## Summary of the Pull Request

Removes some dead code leftover from the keybindings page.

Uses the Segoe MDL2 Assets CommandPrompt icon for as a default icon for a profile that is created in the Settings UI.
![Default Icon for Profile](https://user-images.githubusercontent.com/11050425/99855455-c437fb00-2b3b-11eb-99e9-091e957bc353.png)

Renames the profile.defaults page to "Base Layer" and uses the Segoe MDL2 Assets MapLayers icon:
![Base Layer Icon](https://user-images.githubusercontent.com/11050425/99855506-e16cc980-2b3b-11eb-9de8-121417c64aa2.png)

## References
#1564 - Settings UI

Signed-off-by: Dustin L. Howett <duhowett@microsoft.com>

This fixes the issue with the settings UI where clicking the browse
buttons would cause an exception to be thrown when we tried to display a
picker without an originating HWND.

It turns out that pickers need a hosting/parent window, and Xaml Islands
doesn't furnish us with a CoreWindow that's set up for that use case.
Alas!

Raymond Chen's [blog post on the matter] suggests that we should
hand the HWND off through some classic COM interface. To do that
properly, Terminal's various components need to implement that interface
and propagate the HWND down where it's needed.

Thanks to a [Xaml compiler issue], we can't actually do that. To work
around that, we've begged and borrowed different methods for pushing
HWNDs around:

1. Using IInitializeWithWindow in secret
2. A member that takes a uint64
3. An interface that offers a function that will "wire up" the HWND.

I chose (1) because AppHost can implement IInitializeWithWindow, but
TerminalPage cannot. We're just pretending that TerminalPage _can_.

I chose (2) because none of the Xaml types in TerminalSettingsEditor can
implement the interface thanks to the aforementioned compiler issue, but
we don't have an escape hatch like AppHost that lives in the same module
and can help us do the propagation.

I chose (3) because I didn't want to commit the same sin as (2) _seven
times_ for every different type of settings page that exists. (3) is
backed by "IHostedInWindow", and anybody who knows they have to use
IInitializeWithWindow to tie an HWND to an object can call
IHostedInWindow.TryPropagateHostingWindow() on that object.

House of cards.

[Xaml compiler issue]: microsoft/microsoft-ui-xaml#3331
[blog post on the matter]: https://devblogs.microsoft.com/oldnewthing/20190412-00/?p=102413

## Summary of the Pull Request
Binds `Profile.ColorScheme` to the list of Color Schemes available in the Settings UI.

## References
#1564 - Settings UI

## Detailed Description of the Pull Request / Additional comments
To my knowledge, there is no way to bind an `IMapView` to `ItemsSource`. `ItemsSource` requires an `IObservableVector`, so we need to manually populate `ColorSchemeList` when we navigate to the page.

`CurrentColorScheme` operates mostly like a standard getter/setter, except it needs to account for the upcoming scenario when a color scheme is renamed or deleted. For now, we fallback to Campbell if the scheme was not found. I would like to make it update automatically, but I feel that we have two approaches here:
1. TSM stores `Profile.ColorScheme` as a `ColorScheme` instead of only the name
2. When a color scheme name is modified in SUI, we iterate through all of the profiles and modify `Profile.ColorScheme` accordingly
Open to discuss these options or any other approaches.

## Validation Steps Performed
✅ selected item initialized correctly
✅ list initialized correctly
✅ selecting a new color scheme, then creating a new terminal from that profile uses the new color scheme
✅ setting the color scheme name to a color scheme that does not exist selects "Campbell"

## Summary of the Pull Request
Adds an event handler for the Save and Reset buttons. "Save" writes the settings to disk using the API introduced by #8018. "Reset" simply overwrites the `settingsClone` (what the Settings UI reads from) with `settingsSource` (provided by TermApp on Settings UI initialization).

## References
#1564 - Settings UI

## Validation Steps Performed
The following scenarios were tested and are verified to work properly:
- Change default profile in SUI, then save/reset
- Hide a profile, then save/reset
- Modifying the settings.json directly propagates changes to SUI
- "Reset" updates the current page

## Summary of the Pull Request
Properly binds and polishes controls for a few settings in the Settings UI:
- `LaunchMode` is now bound to a radio button
- "Launch size" was added and bound as two number boxes
- `backgroundImageOpacity` and `acrylicOpacity` are now bound to a Slider control
  - A `PercentageConverter` was introduced to convert from decimal range (0.0-1.0) to whole numbers (0-100)
  - Common styling was added to CommonResources
- `fontWeight` is now bound to a combination of controls:
  - ComboBox is used to display the named values ([FontWeights docs](https://docs.microsoft.com/en-us/uwp/api/Windows.UI.Text.FontWeights?view=winrt-19041))
  - A special `Custom` option is included. When selected, a Slider appears that lets you choose a custom value.
- AcrylicOpacity slider only appears if useAcrylic is enabled

## References
#1564 - Settings UI

## Detailed Description of the Pull Request / Additional comments
bf7d06d is the most complicated commit here. FontWeight is exposed as a `FontWeight` but is constantly treated as a `uint16_t`. The following changes were made to handle this:
- `FontWeightConverter`: bind the slider value to the setting
- `ConversionTrait<FontWeight>` stores the values as `uint16_t` instead of `unsigned int`
- `ConversionTrait<FontWeight>` accepts a range of 1 to 999 in accordance to [FontWeight docs](https://docs.microsoft.com/en-us/uwp/api/windows.ui.text.fontweight?view=winrt-19041)
- manually add and track the `CustomFontWeight` `EnumEntry` for the ComboBox. A sentinel value of 0 is used
- manually implement getter/setter for `CurrentFontWeight` so that the Slider control is shown/hidden appropriately

## Follow-up work for a later PR
The following work items are being added and tracked.
- [ ] non-alphabetical enum ordering
  - FontWeight struggles with this the most. We should order the options from lightest to heaviest.

## Demo
![Slider Demo](https://user-images.githubusercontent.com/11050425/99599265-d71dc480-29af-11eb-9d8a-e32ba975a69e.gif)

![Startup Page](https://user-images.githubusercontent.com/11050425/100675743-63b77380-331c-11eb-83b9-53e28f004e96.png)

…lete

…rminal into feature/settings-ui

To help with organization, I've added headers to group like items together on the profile page.

![image](https://user-images.githubusercontent.com/48369326/101402056-11c89d80-3888-11eb-8ebd-1cbdca6ad0d0.png)

This binds `backgroundImageAlignment` to the Settings UI. A custom control was created for this (see Demo below). The implementation involves...
- storing a reference to all the ToggleButtons
- storing the `ConvergedAlignment` as a tag for each button
- adding the same click handler for each of these buttons, that just clears all the other button states, and activates the current one.

## References
#1564 - Settings UI

## Demo
![Background Image Alignment Control](https://user-images.githubusercontent.com/11050425/100955878-37daf000-34cc-11eb-9378-b73955d93aaf.png)

Tested:
- value matches JSON set one
- clicking on selected value keeps the same button checked
- clicking an unselected button works property

…lete