feat(material): layer shipped CSS for predictable app overrides

[jitterbox]

Summary

• wrap compiled Angular Material component and prebuilt theme CSS in the fixed angular-material cascade layer
• add mat.theme-layer so app-authored theme output can participate in the same layer ordering
• document Tailwind/cascade-layer usage and add tests, including an E2E proof that utility styles override Material predictably

Closes #26451.

Test plan

• pnpm exec bazel test //src/material/core/theming/tests:unit_tests
• pnpm exec bazel test //src/material/schematics:unit_tests
• pnpm exec bazel test //src/material/slider:e2e_tests
• pnpm exec bazel build //src/material/tabs:tabs //src/material-experimental/menubar:menubar //src/material/prebuilt-themes:azure-blue

[crisbeto]

The reason we haven't done this ourselves is that it's super breaking for our internal users and likely externally too.

[alexlehner86]

The reason we haven't done this ourselves is that it's super breaking for our internal users and likely externally too.

I understand that you don't want to introduce unnecessary breaking changes. But I think the advantages of CSS cascade layers (as explained in the linked issue) far outweigh the potential dangers.

I think there are two main scenarios of how Angular Material components are currently used in web applications:

1. The application uses the Material components as they are, applying a pre-built or custom theme. They don't define style overrides for Material. With the changes of this PR, nothing would change for these projects. The Material component styles would still apply, as there are no (unlayered) overrides.
2. The application defines style overrides for Material components, having to define very specific, overly long selectors to win the specificity war. The changes of this PR would allow these projects to simplify their overrides and make their style system more robust.

So I think that this PR would be a great boon for all web developers using Angular Material (myself included).

[DzmVasileusky]

@crisbeto Why not make it optional then?
Leave a layerless version as the default one and implement this as an experimental / optional feature.
We just have to add ! (important) to every tailwind class we are setting on the material components.

[crisbeto]

It's been a while since we looked at it, but I think the problem was that we can't make it optional. The styles with the @layer declaration are baked into the bundle that's shipped to npm.