Extend the token type registry for batched issuance

[chris-wood]

Based on mailing list discussion, it seems like we ought to allow issuance protocols to use batched versions of token type algorithms if they're present. It seems like indicating whether or not a token type admits batching is the cleanest way to accommodate that. This will accompany a proposed change to the batched issuance spec which (1) specifies the BatchTokenRequest/Response media types for issuance, and (2) allocates the ristretto255-based VOPRF token type.

cc @raphaelrobert

[tfpauly]

I'm not totally convinced that we need to add this column of batched to the core docs; it seems to entrench the linking of a particular token type with whether or not it is batched, and I'd prefer to see us have the batching be a detail of how you happen to do issuance, not something that needs to be revealed to the redeeming party.

[chris-wood]

@tfpauly This change specifically makes it so that the redeeming party does not learn whether or not batching was used. Concretely, it would allow us to re-use the existing batch-friendly token type during redemption, but then change how issuance works to actually fetch things in batches.

[tfpauly]

I like what your comment says, but I don't see how adding a column to the token type achieves that, or is necessary for doing that. It seems like this PR does two things: (1) adds the column to the registry, and gives the privacy consideration that starts "Clients that choose to use a batched version of an issuance protocol...".

Could we add that latter paragraph to the batched token doc? And then describe for any particular protocol how you handle both batched and not batched as applicable?

[chris-wood]

Can you make a suggestion? As I see it, the PR here and the one in the batched doc address the comment.