Refactor metric/datagram expectations to have more flexibility

[wvanbergen]

This makes it easier / more natural to construct StatsD expectations, which can be used to assert that the emitted datagrams are as expected.

expectations = []
expectations << StatsD::Instrument::Expectation.increment('counter')
expectations << StatsD::Instrument::Expectation.gauge('gauge', value: 44)
assert_statsd_expectations(expectations) do
  # ...
end

You can also first capture the datagrams, and then run multiple assertion on it:

datagrams = capture_statsd_datagrams do
  # ...
end

# Inject the captured datagrams into the assertion methods.
assert_statsd_measure('duration', datagrams: datagrams)
# Or use the lower level `assert_statsd_expectation` method
assert_statsd_expectation(StatsD::Instrument::Expectation.increment('counter'), datagrams: datagrams)
assert_statsd_expectation(StatsD::Instrument::Expectation.gauge('gauge', value: 44), datagrams: datagrams)

This can be cleaner than having nested assert_statsd_* blocks.

As followups, I will also add:

• ~Using a different client to capture datagrams from~ DONE
• More flexibility for the amount of times a metric is expected.

This is based on use cases I found in Shopiofy's test suite, where the current assert_statsd_* methods are not up for the task and people have to revert to running their own custom assertions on a list of captured metrics.