Trusted Types support in AMP

### Description

AMP uses a number of `.innerHTML` and other potentially vulnerable [DOM sink APIs](https://w3c.github.io/webappsec-trusted-types/dist/spec/#injection-sinks). We would like to make AMP [Trusted Types](https://w3c.github.io/webappsec-trusted-types/dist/spec/#)-compatible by refactoring these API usages to safer patterns.

We will need to:

1. Identify places where DOM sink APIs (such as `.innerHTML` or `.src` assignments) are used.
2. Determine whether the inputs to these assignments are trusted (no possibility of user-controlled input) or not.
3. If trusted, use the [Trusted Types API](https://w3c.github.io/webappsec-trusted-types/dist/spec/#policies-hdr) or a wrapper library like [SafeValues](https://github.com/google/safevalues) to elevate the values to a trusted type before assignment.
4. If untrusted, use a sanitizer and either the Trusted Types API or a wrapper library to elevate the value to a trusted type before assignment.

### Alternatives Considered

We do not have a way to enforce Trusted Types on services that depend on AMP if AMP is not compatible. Since AMP is a widely-used library, we will be blocking a lot of services that would want the security benefits of Trusted Types.

### Additional Context

Trusted Types is the best defense we have against DOM XSS currently and works in conjunction with a strict CSP to cover cases that CSP does not necessarily cover completely.

At Google, AMP is used in a number of our critical services. Trusted Types cannot be enforced on these services if they contain a dependency on AMP, as all the code that runs as a part of the service must be TT-compatible or many JS user interactions won't work properly in Trusted Types enforcement.