Add support for remapping metrics based on a conservative set of transformation operations.

[tobz]

Context

In order to be able to support the DogStatsD Mapper functionality present in the Datadog Agent, we need the ability to be able to remap metrics in a similar way.

We should investigate creating a transform for remapping metrics that has at least as much support is as needed to be at parity with the DogStatsD Mapper, such that it can be added as a synchronous subtransform alongside host and origin enrichment.

Open questions / thoughts

It's unclear to me at the time of writing this issue if remapping would need to happen at a particular point in the pipeline. My intuition is that this could, or perhaps, ought to be a transform downstream of aggregation where we would be modifying fewer metrics, given the string operations involved.

That said, it does imply needing to be able to add tags which we can't do very efficiently yet (#127) but given that bare minimum remapping behavior always involves modifying the metric name anyways, perhaps the worry over tag mutation efficiency is all for naught given that we're going to be creating a new context regardless.

This does also bring up the question of how to do this in a bounded fashion because we'd have secondary context resolving at this point. I mean, that's to say: it's trivial for the transform to have its own context resolver/string interner, and to have it be scoped on the smaller side.... but what do the ergonomics of that look like in terms of configuring it? Does hitting a memory limit on the string interner mean we drop the metric or simply avoid remapping it?