Add sibling-index and sibling-count as custom properties

A bit silly feature idea: introduce optional import(s) (or JS generator in the "bookmarklet" include) emulating upcoming [sibling-count() and sibling-index()](https://github.com/w3c/csswg-drafts/issues/4559) proposal (by some @argyleink dude) in a brute-force ad-nauseam low-key manner:

### `--sibling-index`

```CSS
*:nth-child(1) { --sibling-index: 0; }
*:nth-child(2) { --sibling-index: 1; }
/* ... */
*:nth-child() { --sibling-index: ; }
```
(*), and similarly

### `--sibling-count`

```CSS
*:has(> *:last-child:nth-child()) > * { --sibling-count: ; }
```

or for super backwards ":has()-less" compatibility (or perhaps better performance(?)) the way Lea showcased in the distant past:

```CSS
*:first-child:nth-last-child(),
*:first-child:nth-last-child() ~ * { --sibling-count: ; }
```

Open question remains what initial threshold to pick (1-99?) and whether pre-generate further chunks (100-999, 1000-9999, ...?) in separate includes.

Most probably ideal alternative to includes in client-side environments with scripting available could be a dynamic JS polyfill with lazy mutation observer spitting out additional chunks into in-page `` when maximum sibling count increases somewhere in the tree..

---

(*: I am consciously proposing zero-based indexing here as god intended, even though I clearly know it has zero-chance to be adopted this way; I just had to try 🙃. For `1`-based property I'd propose `--sibling-order`. )

Start by reviewing the existing optional includes and the JavaScript generator in the "bookmarklet" include, then compare the CSS-only and dynamic polyfill approaches described here. Resolve the initial sibling-count threshold and indexing convention before implementation. Done means the chosen approach provides both custom properties with documented limits and coverage for the supported range.

Written by the indexing model from the issue text.