Fix bug where different label orders lead to different results

[dmagliola]

In the DirectFileStore, in order to store the labels hash on disk, we
turn it into a "querystring". The way this is done, we'll end up with
different strings if the same hash is passed in with its keys in
different order.

Since this string is used to index into the file where we store the data,
this will lead to two different values being stored for the same hash.
This is fine in cases where the aggregation is :SUM, because they end up
getting summed when the Client is summarizing. But in :ALL aggregation,
for example, you will end up with one value or the other, randomly.

The test in this commit reproduces this problem.

This way of serializing the labels is a bit slower,
but it's not a huge impact in the big scheme of things, and it leads to
the correct result.

---

Performance impact (based on the labels marshalling benchmark on our "experiments" repo):

  x.report("map into escaped querystring and join") do
    LABELSET.map{|k,v| "#{CGI::escape(k.to_s)}=#{CGI::escape(v.to_s)}"}.join('&')
  end

  x.report("SORT and map into escaped querystring and join") do
    LABELSET.to_a.sort.map{|k,v| "#{CGI::escape(k.to_s)}=#{CGI::escape(v.to_s)}"}.join('&')
  end

map into escaped querystring and join:   507021.8 i/s 
SORT and map into escaped querystring and join:   342933.3 i/s

That's 30% fewer iterations.
The difference ends up being an extra microsecond for this sort, on a metric with 3 labels.
It pains me to add that overhead, but feels worth it for correctness.

[coveralls]

Coverage remained the same at 100.0% when pulling c59713d on fix_label_order_bug into eb1fc97 on master.

[Sinjo]

Tried having a think over alternative ways to perform the sort, but I can't believe anything I came up with is faster than this.