This adds a browserlib module that creates extracts filled with information
about algorithms defined in the spec. The extracts are rather raw: they just
capture the tree structure of algorithms and copy the HTML for each step. This
makes the resulting extracts less directly useful but makes it possible to run
all sorts of analyses on them.

The structure of the extracts is very likely going to change substantively as
we learn from experience!

An algorithm extract is essentially an object with the following keys:
- `name`: The name of the algorithm, when one exists
- `href`: The URL with fragment to reach the algorithm, when one exists
- `html`: Some introductory prose for the algorithm. That prose may well
contain actual algorithmic operations, e.g.: "When invoked, run the following
 steps in parallel". href/src attributes in the HTML have absolute URLs.
- `steps`: Atomic algorithm steps.

Each step is essentially an object that follows the same structure as an
algorithm, except that it does not have a `name` and `href` keys, and may
also have the following keys:
- `operation`: Gives the name of the main operation performed by the step,
when one was identified. So far, that's only for "switch".
- `case`: Used in switch steps to identify the switch condition that triggers
the step.
- `ignored`: Ordered lists found at the step level that do no look like
algorithm steps. Or maybe they are? The lists should get reviewed: they
usually describe inputs/outputs or conditions, but they may signal parts
where the extraction logic needs to be improved. The lists are reported as
text prose.
- `additional`: Each step should contain one and only one algorithm. When
other algorithms are found at the same level, they get reported in that
property. That usually either signals that the spec could be improved
because if fails to use different list items for different steps, and/or
that the extraction logic needs to be smarter.

The `cloneAndClean` logic was completed to drop a few additional informative
bits and to strip the HTML of comments as well, as was done in dfns extraction.
The function is now called from dfns extraction, Web IDL extraction and
algorithms extraction.

The detection only looked at the first step in a list to detect an operation.
This wasn't the intent. The code now looks at all steps. This allows the code
to extract more algorithms and sets of steps than before (dropping a number of
cases that used to report `ignored`).

Now, this update also means that various lists that look like steps but aren't
actual steps get extracted and reported as algorithms. That does not affect the
existing analysis so far, but we'll need to iterate on the logic, for sure.

There should be no normative content in any of these asides. Using one list
avoids duplicating logic partially, as was done until now!

If an ordered list gets captured as introductory prose, that means it was
ignored as an algorithm. Such lists should already get reported in the
`ignored` property and likely don't introduce the algorithm per se.

The code was assuming relative links would only be to same-page anchors, but in a multi-page spec, it could link to a different page of the spec as well

as described in https://infra.spec.whatwg.org/#algorithm-declaration
The extraction criteria ('To ' followed by an exported definition of dfn-type 'dfn' or 'abstract-op') restrictive enough to avoid false positives, but would benefit from checking on real data

per #1614 (comment)

per #1614 (review)

per #1614 (comment)

This re-writes the "one-step" logic slightly to:
1. filter algorithms that are not "one-step" ones directly from within
the `findAlgorithms` function
2. preserve the document order for algorithms
3. not output an empty `steps` property, consistent with how atomic steps
are serialized.

The update also fixes the serialization of switch cases, which introduced an
additional steps level that wasn't needed. Switch cases are now directly
serializes at the `case` level.

When an explicitly flagged algorithm contains a `<dfn>`, that definition is now
used as the anchor to find the introductory paragraph. This is useful for cases
where the spec adds some intermediary paragraph between the actual introductory
paragraph and the steps, as in:
https://url.spec.whatwg.org/#percent-decode

The new logic is not perfect. It cannot spot the cases where the algorithm is
not explicitly linked to the steps, as in:
https://w3c.github.io/webappsec-csp/#abstract-opdef-parse-a-serialized-csp

In that case, the extract will contain two algorithms: first one with the
actual introductory paragraph and dfn, thought to be a "single-step" algorithm,
second one with the actual steps but the wrong introductory paragraph (and no
dfn), because the logic only checks the previous paragraph.

The URL spec also uses `data-algorithm-for` to create a namespace for the
algorithms. Now supported. Example:
https://url.spec.whatwg.org/#percent-decode
https://url.spec.whatwg.org/#string-percent-decode

One spec had an intermediary note paragraph that got picked up as introductory
paragraph:
https://w3c.github.io/webappsec-credential-management/#abstract-opdef-create-a-passwordcredential-from-an-htmlformelement

The code now ignores such informative paragraphs.