Plan out future agility.

[mikewest]

@yoavweiss asked good questions about future evolution of this spec, either adding new algorithms or parameters beyond those currently supported in the profile we've defined. We should add a section to the document sketching out the path we'd expect to take.

[mikewest]

For algorithms, we dropped the alg parameter in #33. Yoav asked:

Does that mean we're forever locked into a single algorithm? Or is there an alternative means of changing it if needed?

Right now, we reject anything other than ed25519. There's no practical difference between that and rejecting any alg parameter, insofar as you'll need to support this format while it's still a thing browsers understand.

If we'd like to support a new algorithm, we have basically the same set of options as we had prior to #33:

1. Bring back the alg parameter with a new value.
2. Infer the algorithm from metadata (perhaps Ed25520 public keys will be 257 bits long, perhaps we'll encode the key in some ASN.1-like format that includes an algorithm identifier).
3. Define a new profile that's suitable for the new algorithm (see also Shift the message signature profile to a more specific type. #34).