Supposed to be used when component is placed within another control that already provides external borders. Should not be confused with 'no-border' style. Some controls in the 'edge-to-edge' mode still need a border, e.g. toolbar always needs the bottom border.
The main problem of the old approach is that variables which contain real color
name (blue, green, red) were exposed as looked-up colors. This is because
GitHub Primer only specifies four functional variables for each color
(foreground, emphasis, muted and subtle) and only three of them can be used as
background color, which is clearly not enough to create hover, pressed or other
color effects. So, we can either use dynamic color modification functions,
which can lead to less predictable results, or use colors from the predefined
color palette, or create a bunch of the ugly named color variables for every
combination (`-color-accent-muted-hover`, `-color-accent-subtle-hover` and so
on) for general purposes.
Still, it worked fine until changing accent color feature wasn't implemented.
To fully change accent or any other color, one should change not only the
functional variables, but also the corresponding color scale, which is
responsible for background effects. As an outcome, if we change the accent
color to purple, we end-up with `-color-accent-emphasis` which is purple and
`-color-blue-5`which is also purple. That's just confusing.
This commit resolves this by renaming all color scale stuff to functional
variables. So, `-color-blue-*` becomes `-color-accent-*` and so on, and this
long explanation supposed to serve as a reminder that nothing is perfect and
this is just another trade-off example.
Color shades should be declared upfront without resorting to the dynamic brightness modification functions. All shades are also exposed as looked-up colors.
