[css-cascade] allow a second value for the `all` property that is a list of exceptions

[knowler]

Currently there is no in-between API for setting a list of properties to the same value: it’s either all or setting each individual property. It would be nice to have more granular shorthands:

1. Using all, but being able to specify exceptions, perhaps, as subsequent values in the existing syntax (e.g. all: revert-layer not background-color, color).
2. Or being able to be specific about the list of properties you want to set to a value. Mixins likely solve this case, though it likely doesn’t do much to change the authoring experience for a single use (i.e. their benefit would be most seem if one had to do this multiple times in a codebase).

In the Shadow DOM, this would be helpful when exposing shadow parts or for styling slotted content or even the shadow host. Currently, if I want to limit my element’s CSS API, I have to either set each of those properties to !important or set all: revert-layer !important in my unlayered styles, then use custom properties for each property:

/* These styles are in a shadow root */

[part="button"] {
  @layer styles {
    /* Properties I want a consumer to be able to customize */
    background-color: var(--background-color, SeaGreen);
    color: var(--color, White);
    /* Properties that I need to set that I don’t want a consumer to customize */
    pointer: cursor;
  }

  /* Prevent the consumer from using non-custom properties for styling the part */
  all: revert-layer !important;
}

Outside of the Shadow DOM, this is also helpful in a layered stylesheet since one might want to prevent a subsequent layers from styling certain properties on an element. The existing technique to do this is the same one I demonstrated for the Shadow DOM above (I also have an article explaining this technique).

[Loirooriol]

Part of the discussion in #8726 seems related, e.g. https://github.com/w3c/csswg-drafts/issues/8726#issuecomment-1565754235

Using all, but being able to specify exceptions, perhaps, as subsequent values in the existing syntax

Shorthand declaration need to be expanded into longhand declarations at parse time. Thus the list of longhands shouldn't be based on the provided value, which is not known until computed-value time (e.g. there could be a var()).