Persistent collections updates

[lorentey]

Start ingressing the persistent collections code.

• Review, update benchmarks
• Reformat code to follow Standard Library conventions
• Rename internals to follow The Leading Underscore Rule
• Start reorganizing type definitions per stdlib conventions
• Prefer nested types to top-level generics (wip)

There is no functional change as of yet.

Checklist

• I've read the Contribution Guidelines
• My contributions are licensed under the Swift license.
• I've followed the coding style of the rest of the project.
• I've added tests covering all new code paths my change adds to the project (if appropriate).
• I've added benchmarks covering new functionality (if appropriate).
• I've verified that my change does not break any existing tests or introduce unexplained benchmark regressions.
• I've updated the documentation if necessary.

[lorentey]

(The code formatting changes and large scale renamings/reorganizations make this effectively non-reviewable, I know. 😔)

[msteindorfer]

LGTM

See clarifications and minor comments.

[msteindorfer]

The minimal requirement would be BinaryInteger for the trailingZeroBitCount property.

Suggested change

	extension FixedWidthInteger {
	extension BinaryInteger {

[lorentey]

Sure, however, we don't need to over-generalize things -- I kept the ability to change Bitmap to a different type (for now), but I don't expect we'll ever exercise this freedom, and we definitely don't change it to a non-fixed-width integer type. (_NonzerBits is not public.)

[msteindorfer]

Suggested change

	internal struct _NonzeroBits<Bitmap: FixedWidthInteger>
	internal struct _NonzeroBits<Bitmap: BinaryInteger>

[msteindorfer]

The _BaseIterator and _BaseReverseIterator code generically against the higher level _Node protocol instead against the persistent dictionary internals.

The main rationale of keeping the generic _BaseIterator was to abstract over the PersistentDictionary and (future) PersistentSet that may vary in terms of internal representation.

For now this struct is indeed unused, since the PersistentDictionary contains a lower level iterator implementation, coding against it's internal implementation.

[msteindorfer]

The range(Insert|Remove)Reversed functions may need to be restored once we switch back to the native CHAMP ordering where the buffer grows from both ends inwards (similar to heap and stack).

(At the moment the dictionary node caches the offset to the sub-node section and grows all buffer segments from left to right, which is a relic of experimenting with various explicit hash-collision resolution strategies. )

[msteindorfer]

The count and the capacity fields should eventually also move in the header, to have division between header and buffer akin to ManagedBuffer.

Then it also makes send to have the Capacity typealias inside the _NodeHeader.