Add text describing composition of multiple token types

[chris-wood]

Currently, origins can challenge clients for any number of token types and clients pick the ones they support (and prefer). This is fine for equivalent token types, like those in the basic issuance doc, since the origin is willing to accept either and they have no substantial difference in functionality or security. However, the origin can also do silly things like combine basic and rate-limited token types in the same challenge. What the client should do in this situation is a bit odd, since the incentives may not be aligned between client and server. We should add some text discouraging this practice, and maybe even try to state which token types are equivalent from a feature and security perspective.

[chris-wood]

This is an architecture issue, not a rate-limited issue, so let's move it over to the architecture draft.