[OF-1733] feat!: Read default settings from login

[MAG-ElliotMorris]

Read the default settings now returned from login, and provide them in the LoginState return.

As LoginState is common, had to move existing settings structures to common also, which is what makes this a breaking change.
This entailed the removal/splitting up of the ApplicationSettings.h file, I've just put the stuff that remained from there in ApplicationSettingsSystem

Breaking Changes

• csp::systems::SettingsCollection relocated to csp::common::SettingsCollection.
• csp::systems::ApplicationSettings relocated to csp::common::ApplicationSettings.

New Api
Returned object from Login, LoginState now contains:

• csp::common::List<csp::common::ApplicationSettings> DefaultApplicationSettings
• csp::common::List<csp::common::SettingsCollection> DefaultSettings;

Important

The test will fail until CHS have resolved their issue with seeding Local MCS. Internal slack thread here. It passes against live MCS.

This change is rather non-symmetric. Mapping UserSettings to SettingsCollection but not mirroring the same with ApplicationSettings makes it rather tricky to reason about what setting is relevent to the SettingsSystem and what isn't, both from an api consumer perspective as well as a library developer trying to maintain module boundaries perspective. You'll see some of that in this PR.

[github-actions]

🚀 Pull Request Review Guidelines

Thank you for taking the time to review this Pull Request. The following is a summary of our Pull Request guidelines. The full guidelines can be found here.

💬 How to Provide Feedback

We use a comment ladder when leaving review comments to avoid any ambiguity.

Tag	Is response required?	Is a change required?	May the PR author resolve?
[Fix]	✔️	✔️	❌
[Consider]	✔️	❌	✔️
[Question]	✔️	❌	❌
[Nit]	❌	❌	✔️
[Comment]	❌	❌	✔️

All comments should be prefixed with one of the above tags, for example:
[fix] Your editor is still set to use tabs instead of spaces, or this file is old and needs to be reformatted.

⚠️ Reviewers should be sure to resolve conversations if they feel their feedback has been addressed sufficiently.

🎯 PR Author Focus Areas

• Link Commits to Conversations After making a change in response to a reviewer's comment, link the specific commit in the comment thread. This will allow the reviewer to view the change without having to hunt the codebase for it.
• Breaking Changes Any breaking changes made to the public interface must be specifically called out in the PR. The preferred format is a bullet list enumerating the specific nature of the change/s, as well as the types and method signatures that are affected. If necessary, migration guidance should also be provided here.

Thanks again for taking the time to review this Pull Request.

[MAG-ChristopherAtkinson]

Overall the changes look good, @MAG-AdamThorn raise a good point around result objects that I have commented on, will leave this unapproved until thread are resolved.

[MAG-ElliotMorris]

@MAG-AdamThorn @MAG-ChristopherAtkinson

We can't move the Result objects themselves to Settings.h because they are not common types, so they can't be in the include set of that file. I will have to re-instate the deleted file.

[MAG-ElliotMorris]

I have also added a commit that disables the test on local mcs, hopefully temporarily. CHS have tried to ship changes that seed local MCS but it hasn't taken properly as yet.

Proof that this works against live, since there's really no proof in the PR given the local MCS seeding issue: