Define extension client processing more carefully.

[jyasskin]

#347 defines the "client processing" term for use in makeCredential() and getAssertion(), but it doesn't yet define an input and output format for the data, and it doesn't fix up the actual client processing definitions to have defined output. For example, https://w3c.github.io/webauthn/#extension-txauth refers to "default forwarding of client argument to authenticator argument.", but nothing has defined that default forwarding.

In that definition, I'm tempted to use canonical CBOR (since arbitrary CBOR is likely to increase parsing difficulty, which will cause vulnerabilities in authenticators), but:

1. We'll need some more details defined locally, like double vs float format, to make it actually canonical.
2. Not all JS objects can be serialized at all. We'll probably want to conceptually go through JSON.stringify in order to get a deterministic result for those.

[equalsJeffH]

@vijaybh suggested here https://github.com/w3c/webauthn/pull/347/files#diff-ec9cfa5f3f35ec1f84feb2e59686c34dR496:
I think we should base64url encode those just as we do with the challenge. Need to update client processing sections of extensions, maybe this should be part of #363.

[selfissued]

The [=client extension processing=] and [=authenticator extension processing=] inputs and outputs and representations are now well specified, since PR #389 has been merged. All the stuff about "default forwarding of client argument to authenticator argument" is gone. @jyasskin - if you agree, let's close this one. If you disagree, please say what additional steps need to be taken to address this for overall extension processing.

If there are specific issues remaining on the processing rules or representations for particular extensions, let's file individual issues against them. There's at least one that I have in mind myself...

[jyasskin]

Anything else can definitely be a separate issue. It's much clearer now than when I filed this one. Thanks!