`HTTP2Frame` Payloads as an implicitly @_frozen enum.

Even in Swift 5, enums defined outside of the standard library, C headers, and swift overlays will be considered frozen and immutable, meaning that a modification to one will be a semver-major version-breaking change. Our `HTTP2Frame.FramePayload` type is (still) an enum, and we literally cannot do anything about it without dropping in a C header enumerating the known frame ID values.

There are already two published RFCs that have added new frame types to HTTP2: the ALTSVC frame defined by [RFC 7838 § 4](https://tools.ietf.org/html/rfc7838#section-4) and the ORIGIN frame defined by [RFC 8336 § 2](https://tools.ietf.org/html/rfc8336#section-2). Those are included already (or are going to be included in my encoder/decoder patch), but more will doubtless arrive at some point.

Is there anything we can do about this? My original implementation used a Frame protocol and subtypes, with a switch over the type (i.e. `case is DataFrame:` or `case let x as DataFrame:`) to disambiguate them. Is this a better option, and if so, shouldn't we try to land this before swift-nio-http2 transitions off its nghttp2 dependency altogether?

Start by reading the HTTP2Frame.FramePayload definition and the encoder/decoder work mentioned in the issue, then compare the existing enum design with the proposed Frame protocol and subtype approach. Done means agreeing on an extensible representation for future HTTP/2 frame types and implementing it without relying on the nghttp2 dependency transition.

Written by the indexing model from the issue text.