[css-borders][css-images] Properly address border image use cases, and kill `border-image` with fire

Background

Overall border-image is a mess, and most authors won't touch it with a bargepole unless they really have to (per the 2022 Almanac it is used on < 7% of pages, which seems way lower than the frequency of actual border image use cases).
It doesn't cover enough related use cases, and even when it does, its syntax is confusing.
Several issues exist to patch some of its holes, either by tweaking border-image itself, or by adding syntax to other parts of CSS to address them, e.g.:

• https://github.com/w3c/csswg-drafts/issues/9456
• https://github.com/w3c/csswg-drafts/issues/9183
• https://github.com/w3c/csswg-drafts/issues/9263
• https://github.com/w3c/csswg-drafts/issues/8802
• https://github.com/w3c/csswg-drafts/issues/7550
• https://github.com/w3c/csswg-drafts/issues/7777
• https://github.com/w3c/csswg-drafts/issues/7457

Its syntax also has issues:

• https://github.com/w3c/csswg-drafts/issues/6739

Fixing border-image

It seems to me that there are three fundamental problems with border-image:

1. It conflates two orthogonal concepts: 9-slice scaling is useful for images in general, and using images for borders is useful with or without 9-slice scaling.
2. It doesn’t play well with other properties, like border-radius. Presumably this was done because border-image was designed before @supports, so we probably thought border-radius and border can be used to provide a decent fallback?
3. It doesn’t cover all relevant use cases

It’s probably not worth trying to reuse border-image for this, since border-image: <image> is valid syntax, it will impose severe restrictions in terms of what we can do. Perhaps border-layer could work (since we recently added background-layer) and naturally affords multiple images. We could even move the <image-1D> syntax to that, which currently awkwardly sits in border-color.

For 1, I think a good way forwards would be to offload the scaling logic to @image and have border-layer only deal with assigning one or more <image> values to border parts and doing reasonable things by default.

For 2, it seems obvious that whatever replaces it should naturally follow border-width, border-radius, border-style etc. it could also have corresponding side longhands for specifying separate images per border.

For 3, I think the main categories of use cases are, in order of less to more control:

1. Entire image used in the border area (see use cases for #9456)
2. 9-slice scaling
3. Separate images for sides/corners with auto-flip/rotate
4. Separate images for sides/corners with no modification

One potential design, just to get the conversation started:

border-layer-source: <image>#
border-layer-align: [ auto | normal ]#;
border-layer: [<border-layer-source> && <border-layer-align>?]#

With potential border-<side>-layer / border-<corner>-layer shorthands for separate images per side/corner.

Start by reading the CSS Borders draft and the linked issues, especially the discussions about border-image use cases, syntax, and image scaling. Compare the proposed border-layer direction with the listed use cases and related CSS properties. Done means the working group has agreed on a sufficiently scoped design and specification changes to pursue.