Handle Composition on Uno in Animations component

Nessuno ha ancora preso questa issue.

## Background

Calls to Composition inside of ImplicitAnimationSet were causing the ColorPicker to fail to show on Wasm in [this PR](https://github.com/CommunityToolkit/Windows/pull/241#issuecomment-1899107130). We're referencing the Animations component for `ImplicitAnimationSet`, but implicit animations use Composition, which aren't implemented on Uno yet.

Our options were to either:
- Add conditional XAML everywhere `ImplicitAnimationSet` is used, or
- Update `ImplicitAnimationSet` to avoid calling Composition APIs when running under Uno until support is added.

> Can we combine conditionals with a namespace like that in Uno?

[Official Uno docs](https://platform.uno/docs/articles/platform-specific-xaml.html#example-2) recommend wrapping it in a container such as a Grid. That requires adjusting the Visual Tree in a lot of different places, both in our codebase and in the codebase of those consuming our packages

> We do need a better way of tracking what's not supported in Uno though doing it that way, right? As it's not like we'd have it throw an unsupported exception.

At a high level, our custom MultiTarget system is designed to mitigate this happening on accident by allowing us to isolate code that depends on unsupported APIs (e.g. Composition) into separate libraries (e.g. Media) and disabling Uno-specific `MultiTarget`s so they can't be used without first adding support and checking/addressing the original reason for lack of support.

When we enable Uno for a component that didn't previously support it, we need to be doing a sweep of the component to make sure nothing throws when running under the new platform.

## The problem

We didn't originally support the `wasm` MultiTarget for `Animations`, but we added \*partial\* support for running on Uno through the `FrameworkLayer` abstraction, though this support only extended to `AnimationBuilder` and [`CustomAnimation`](https://github.com/CommunityToolkit/Windows/blob/2735c8718984daa2ddee7a5aa9235f57bead0df7/components/Animations/src/Xaml/Abstract/CustomAnimation%7BTValue%2CTKeyFrame%7D.cs#L36). Other code is still in place that calls to the Composition APIs on Wasm, which will throw out of the box.

Giving the Animations package a quick once-through, I've also noted that:
- `CustomAnimation` isn't being used by our inbox animations (TranslationAnimation, ScaleAnimation, etc) despite inheriting the same type. They won't default to `FrameworkLayer.Xaml` on Uno.
- Implicit/Explicit animations and helpers are still using Composition APIs directly without handling what to do when running under the added Uno tfm

## The solution

The above isn't an exhaustive list. We should do a full sweep of the Animations package to see what can either:
- Be implemented without using Composition (if needed enough), or
- Be disabled so it doesn't throw when people use it, while we wait for Uno to implement Composition.

_Originally posted by @Arlodotexe in https://github.com/CommunityToolkit/Windows/issues/241#issuecomment-1899195079_

Start with the Animations package and CustomAnimation{TValue,TKeyFrame}.cs, then review FrameworkLayer, AnimationBuilder, the inbox animations such as TranslationAnimation and ScaleAnimation, and the implicit/explicit animation helpers. Sweep the package for Composition API calls on Uno/Wasm and verify that supported paths work without throwing; disable or replace unsupported paths as appropriate.

Scritto dal modello di indicizzazione a partire dal testo della issue.