Flesh out ACME interface

[davidben]

Filing this to capture TODO in the doc

[aarongable]

From an absolutely minimalist perspective, ACME can do almost everything necessary for MTC today:

• the newOrder request contains a list of identifiers
• fulfilling challenges to prove domain control remains the same
• the finalize request should be updated to not contain a CSR (to avoid big x509 structures and signatures in the MTC world), but otherwise works the same
• finalization would take a long time (up to batch_duration minutes) but ACME already supports async finalization
• after finalization, the order's certificate URL would return a (base64-encoded?) BikeshedCertificate rather than a PEM-encoded x509 Certificate

That's just two minor changes for the most basic level of support.

But, that leaves on the floor a few key questions:

• How do subscribers request an MTC? Do they make their requests to a wholly different ACME server (different base directory url, etc)? Do they include some information in the newOrder or finalize request indicating that they want an MTC?
• How do subscribers get both an MTC and a backup traditional certificate to use before the new batch is issued and propagated to browsers? Do they make separate newOrder requests (and potentially fulfill separate domain control challenges) for each kind? Do they make a single newOrder request which then creates multiple Order objects to be finalized separately? Does a single Order end up with multiple different certificate download links after finalization?
• Imagining the future pointed at by the current draft's extensible ProofTypes, how does an ACME server indicate to the client which certificate they should present in which circumstances?

I'm personally leaning towards a world where a single newOrder request can end up resulting in issuance of multiple certificates for the same pubkey+identifiers. Perhaps where the finalized Order object contains a list of both certificate download URLs and metadata about each of those certificates.