Drop "Compatibility Profiles" section.

This section was imported from RFC 6637, but it is confusing, incomplete, outdated, and duplicative.

It is confusing because it is called "Compatibility Profiles", a general name, but it only references algorithms in combination with various Elliptic Curve choices. This made more sense when it was part of RFC 6637, but doesn't make as much sense in a replacement for RFC 4880.

It is incomplete because it offers no attempt at "Compatibility Profiles" that use non-ECC asymmetric crypto. We could rename it to "Elliptic Curve Compatibility Profiles", but that would just leave the document as a whole without additional guidance for non-ECC algorithms.

It is outdated because it refers to Suite B, which has been deprecated by its authors (see RFC 8423).

And it is duplicative, because it places additional constraints on MTI requirements that we're working on actively as part of the cryptographic refresh of RFC 4880.

The simplest thing seems to be to drop the section entirely.

Further work on algorithm implementation/deployment requirements might suggest creation of new, up-to-date compatibility profiles that cover the cryptographic suites likely to be used together, but if that work happens, it should be done in consultation with the CFRG. It should be clearly documented, narrowly-targeted, up-to-date, and non-conflicting with whatever MTI requirements we land on.