simplify TimeLimiter, fixing its tests

[Dieterbe]

• previous implementation (introduced in Dont let pruning hold the index too long #1065) was a bit hastily implemented and
  much more complicated than needed:
  trying to support concurrency but not doing it well, while
  we don't actually need any of it.
• unit testing was very flakey, in particular in circleCI there's
  lots of timing inaccuracy leading to broken tests
• it was inaccurate, for shortlived operations it would be negligible
  but for longer operations it is not. While our use case operations
  should be short, it is nice to be able to fix this while we're at it.

So now we simplify the design a lot, basically reduce it to
a non-concurrent accounting structure, removing all channels,
goroutines and context, making the accounting more correct
and the testing more robust.

[Dieterbe]

this fixes borken tests like

=== RUN   TestTimeLimiter
--- FAIL: TestTimeLimiter (0.00s)
    time_limit_test.go:19: scenario window 1: work done: 0 - wait should be 0. was supposed to take 0s, but took 157.989µs
FAIL
FAIL	github.com/grafana/metrictank/idx/memory	18.739s

e.g. as seen in unrelated PR's such as #1021

[Dieterbe]

contrary to what i said in #1087 I now think we shouldn't add benchmarks to this, because:

1. it's trivial to see that any Add() call will have very little overhead
2. ditto for Wait()
3. TimeLimiter states For correctness, you should always follow up an Add() with a Wait() so that's also how you should call it in benchmarks, but of course Waiting slows down the benchmarks based on what the limit was, rendering it pointless.

[woodsaj]

dont panic, return an error. Let the caller decide if they want to panic or not.

[Dieterbe]

@woodsaj PTAL