two-bucket: Do not constrain bucket representation to Strings

[petertseng]

The description currently specifies that buckets are represented, in
both the input and the output, as strings.

This seems overly constraining. Consider those tracks that wish to
represent these buckets as variants of a tagged union or of an enum for
the purpose of better type safety. These tracks have these options in
order to do so:

• Accept the problem-specifications README as is, but act in
  contravention of it. But it is confusing if the README contradicts the
  tests.
• Create a custom description.md. But this is a little unfortunate
  because only two lines need to change, and it adds extra maintenance
  burden to have to maintain the custom description.md. Consider that if
  this description.md changes, the changes will probably need to be
  copied to each custom description.md
• Add to .meta/hints.md saying something to the effect of "ha ha ignore
  the above text about using Strings, we're using tagged unions / enums"
  so that this will be appended to the description. But it seems too
  strange to have a README contradict itself.
• Other solution I did not think of.

Removing the specification of the buckets as a string allows the
flexibility, but now it acquires some inconsistency. All inputs/outputs
that are numeric are explicitly stated to be so, but the specification
is silent on the bucket representation. It would not be unreasonable for
a reader of this specification to say "But wait! You told me what types
all the other inputs/outputs are, why didn't you tell me about the
buckets?"

If this commit is accepted, it implies we value the flexibility over
the consistency.

Closes #990 by mutual exclusion.

[Insti]

I approve of this PR but I approve of the other one more.