I did quite a lot of research about how to encode `/` in RESTful
request URLs. There doesn't seem to be a general consensus how to do
it (besides just not to do it). I found a few cases where systems
would accept base64 encoding (which has to be the "URL and Filename
safe" variant, otherwise you have `/` in there again, but at least the
existence of this varian it RFC 4648 tells us that it is kind of meant
for what we are doing here). But then the next problem arises: How to
mark what is base64 encoded and what is plain text? In most cases I
saw, the respective field is just marked as being always base64
encoded, which would be sad for our case as there are very few
situations where you actually need base64 encoding. One case used a
marker like `$base64:...`, which I found quite weird. However, I think
using some kind of marker is a good idea. I picked a leading `=` here
as that's a character that is rarely used as a first character of a
label value (and hopefully even less so for the label value in a
grouping key).

I put details in the documentation (see README.md in this commit).

As illustrated there, a nice byproduct is that the encoding of special
characters is a bit saner now (imagine Chinese letters in label
values, which might be pretty common in, well, China).

As base64 encoding is readily available in standard libraries and even
as command line tools (again see examples in the documentation), I
think this is a pretty doable and not overly invasive way of dealing
with the problem.

Client libraries should of course support this encoding transparently.

The competition is mostly going away from the RESTful style and use
URL parameters. If we completely switch to it, we would break
everything hard. If we offered it as an alternative, we would deviate
from our best practice of only offering one way of doing one thing. It
would be a quite invasive change either way.

We could also use a custom escaping scheme just for the case of `/`,
but there is no precedent for that. We would have a solution only used
for the Pushgateway, and everyone had to implement that escaping
scheme on their own. (base64 is a more complex encoding, but the
tooling is readily available everywhere.)

Signed-off-by: beorn7 <beorn@grafana.com>