Improve documentation of ECC Point Formats

The ECC point encoding rules introduced in crypto-refresh-02 (taken from RFC 6637) seem fragile and easy to get wrong, especially as expanded from the introduction of Curve25519's representation.

I think it would be worthwhile to try to write down the rules for point encoding clearly and deliberately, and to treat the ECC point compression "flag byte" as its own registry, rather than throwing it in as an aside in the appendix. By asking IANA to register a table of these "flag bytes", we'll probably help clarify our own thinking about what belongs in that table (e.g. are there specific things that need to be known about each flag, how can it be used), and maybe some of the other tables as well (e.g. in the ECC Curve OIDs table, maybe we want to refer to the preferred representation for each curve?)

The initial values of the "flag byte" registry should probably just include 0x04 and 0x40 (the only two directly contemplated by the draft), and leave speculative uses like 0x41 and 0x42 for later definitions.

The draft suggests that applications should only use special encodings ("conversion formats") if they are not "in doubt that any recipient can support it", but offers no mechanism for signalling or detecting that support, which itself is a bit problematic.