Phantom types: More properties, pseudo-stuff and a few fixes

[dzuk-mutant]

I want to try to get the phantom-types branch much closer to completion while I have free time ^^

My goal with this PR is simply filling in a lot of relatively simple properties that have not yet been made, don't really do anything new and don't really shake anything up.

New stuff

This PR implements the following:

psuedo-classes

• :checked
• :empty
• :enabled
• :first-child
• :first-of-type
• :focus
• :fullscreen
• :hover
• :in-range
• :indeterminate
• :invalid
• :last-child
• :last-of-type
• :link
• :only-child
• :only-of-type
• :out-of-range
• :read-only
• :read-write
• :required
• :root
• :scope
• :target
• :valid
• :visited

pseudo-elements

• ::backdrop
• ::cue
• ::marker
• ::placeholder
• ::selection

Logical border radius

• border-end-end-radius
• border-end-start-radius
• border-start-end-radius
• border-start-start-radius

Logical snap scrolling metrics

• scroll-margin-block
• scroll-margin-block-end
• scroll-margin-block-start
• scroll-margin-inline
• scroll-margin-inline-end
• scroll-margin-inline-start
• scroll-padding-block
• scroll-padding-block-end
• scroll-padding-block-start
• scroll-padding-inline
• scroll-padding-inline-end
• scroll-padding-inline-start

Overscroll behavior

• overscroll-behavior
• overscroll-behavior-block
• overscroll-behavior-inline
• overscroll-behavior-x
• overscroll-behavior-y

Inset and logical insets

• inset
• inset-block
• inset-block-end
• inset-block-start
• inset-inline
• inset-inline-end
• inset-inline-start

Logical dimensions

• block-size
• inline-size
• max-block-size
• max-inline-size
• min-block-size
• min-inline-size

Logical overflow

• overflow-block
• overflow-inline

Missing gap properties

• row-gap
• gap

Typographic properties

• quotes
• text-overflow
• line-break
• The two and three-argument forms for hanging-punctuation

Missing font properties

• font-kerning
• font-language-override
• font-optical-sizing
• font-synthesis
• font-variant-east-asian
• font-variant-position

transforms

• rotate
• scale

perspective

• perspective
• perspective-origin

SVG

• paint-order

Misc

• resize
• contain

Values and types

• Various values have been suffixed with _ to make way for new properties where conflicts occurred.
• Various variable names in functions have been renamed to avoid conflicts with new values.
• According to MDN, scroll-margin properties should only take Lengths, not LengthSupported {auto : Supported}, so I changed the code for all the pre-existing ones to make that the case.
• I noticed that width and height's type annotations didn't account for the number of values they could actually support, so I changed them.
• Added the clip value to the overflow properties that support it.

Other changes

• Fixed some typos in the documentation for pre-existing scroll-padding functions.
• Rearranged some properties so they grouped together better based on functionality, like putting all the gap properties together because they don't just apply to grid layouts anymore.

Things I'm unsure of

• For rotate, instead of creating a rotate4 with three vector ints and an angle, I decided to create a rotate2 that can accept a new value called vec3. Once again I'm not sure if this is idiomatic but (vec3 1 1 1) seemed more elegant and semantic than doing (int 1) (int 1) (int 1).

I hope this is all okay! Sorry for doing 3 separate PRs for adding all these, this was kind of impromptu and I wasn't sure how many I was gonna do ^^' (I'm pretty new to doing PRs). I also figured that it might be best that I keep adding stuff I was working on into this one until someone takes a look to avoid making lots of PRs and so others wouldn't need to handle the merge conflicts.

[dzuk-mutant]

I hope this wasn't an overreach but while I've been doing these basic additions, I noticed that there were a bunch of value functions that were in weird places and value functions that should probably be in the Shared Values section of the docs but weren't, so I decided to go through the whole Css module and group up all the values that were used in multiple different types of properties and bring them into the shared values section, which ended up being:

    [...]
    , auto, none, normal, strict, all_, both, always
    , hidden, visible
    , contentBox, borderBox, paddingBox
    , left_, right_, top_, bottom_, block, inline, start, end
    , x, y
    , stretch, center, content, fill_, stroke, text, style
    , clip, cover, contain_
    , baseline, sub, super, ruby, fullWidth
    [...]

I also altered their documentation to make light of the fact that they are used by different kinds of properties if their docs didn't mention it.

I moved url() up to be with the other value functions in the docs and the code because it was originally sitting under the SVG section.

I also noticed the levels of headings weren't consistent, so I made them consistent.

[dzuk-mutant]

I'm gonna mention it in the phantom types thread but I noticed that when it comes to the documentation of CSS values in this module, some docs link to to the values section of the property that uses this value on MDN and use the property's CSS name:

{-| The `scroll` value used for properties such as [`overflow`](https://developer.mozilla.org/en-US/docs/Web/CSS/overflow#Values) and [`background-attachment`](https://developer.mozilla.org/en-US/docs/Web/CSS/background-attachment).

    overflow scroll

    backgroundAttachment scroll

-}
scroll : Value { provides | scroll : Supported }
scroll =
    Value "scroll"

...while others reference the Elm documentation and the Elm function name for that property.

{-| The `url` value for the [`cursor`](#cursor),
[`fill`](#fill),
[`strokeImage`](#strokeImage),
and [`backgroundImage`](#backgroundImage) properties.
-}
url : String -> Value { provides | url : Supported }
url str =
    Value ("url(" ++ str ++ ")")

As far as I know there isn't a consistency rule for what it should be? (All the stuff I've written so far use URLs to the Elm functions and use the Elm function naming for properties)