Split Microsoft.Toolkit.Diagnostics package (#3726)

### Related to #3594, working towards reducing footprint and increasing modularity

<!-- Add a brief overview here of the feature/bug & fix. -->

## PR Type
What kind of change does this PR introduce?
<!-- Please uncomment one or more that apply to this PR. -->

<!-- - Bugfix -->
<!-- - Feature -->
<!-- - Code style update (formatting) -->
- Refactoring (no functional changes, no api changes)
<!-- - Build or CI related changes -->
<!-- - Documentation content changes -->
<!-- - Sample app changes -->
<!-- - Other... Please describe: -->


## What is the current behavior?
<!-- Please describe the current behavior that you are modifying, or link to a relevant issue. -->
The `Guard` and `ThrowHelper` APIs are part of the `Microsoft.Toolkit` package.
This has a few downsides with respect to binary size for consuming package and overall API surface for consumers.

The `Guard` and `ThrowHelper` APIs relied on a number of different NuGet packages that needed to be pulled in:
 - `System.Diagnostics.Contracts`
 - `System.ValueTuple`
 - `System.Memory`
 - `System.Runtime.CompilerServices.Unsafe`

These packages are _only_ needed by those APIs, and yet with `Microsoft.Toolkit` being referenced by every other package in the whole Toolkit, every other package ended up having a dependency on those as well even when there was no use for them at all. This is not ideal both for final binary size, for the increased number of potentially unwanted APIs being imported by consumers, and due to the fact that many consumers want to minimize the number of NuGet dependencies in general.

Furthermore, the `.Diagnostics` APIs can be very useful for all kinds of developers, especially those working in backend scenarios and with a particular focus on performance. It was not ideal to force those developers to also import APIs such as observable collections and other more UI-oriented APIs that were available in the base package (in fact I've spoken with a few devs that didn't like having to include anything other than just the `Guard` and `ThrowHelper` APIs when adding the package).

For consumers on .NET 5 that don't use .NET Native, splitting the `Guard` and `ThrowHelper` APIs away means 80KB less in binary size (when not using IL trimming) when those APIs are not needed, which is effectively a 75% reduction on the base package.

## What is the new behavior?
<!-- Describe how was this issue resolved or changed? -->
The `Guard` and `ThrowHelper` APIs have now been moved to a new `Microsoft.Toolkit.Diagnostics` package.
Splitting this package completely removes all those dependencies from all other packages too 🚀
This work will also make it easier in the future to introduce a `.Diagnostics` source-only package, if we wanted to.

**Note:** marking as breaking change due to the APIs being moved to a different package, but this PR doesn't do any changes to the overall API surface across the various packages - the APIs are still all exactly the same, just modularized differently.

## PR Checklist

Please check if your PR fulfills the following requirements:

- [X] Tested code with current [supported SDKs](../readme.md#supported)
- [ ] ~~Pull Request has been submitted to the documentation repository [instructions](..\contributing.md#docs). Link: <!-- docs PR link -->~~
- [ ] ~~Sample in sample app has been added / updated (for bug fixes / features)~~
    - [ ] ~~Icon has been created (if new sample) following the [Thumbnail Style Guide and templates](https://github.com/windows-toolkit/WindowsCommunityToolkit-design-assets)~~
- [X] New major technical changes in the toolkit have or will be added to the [Wiki](https://github.com/windows-toolkit/WindowsCommunityToolkit/wiki) e.g. build changes, source generators, testing infrastructure, sample creation changes, etc...
- [X] Tests for the changes have been added (for bug fixes / features) (if applicable)
- [X] Header has been added to all new source files (run *build/UpdateHeaders.bat*)
- [ ] Contains **NO** breaking changes

Author: msftbot[bot]