`time_this` api and `partial`s

[mambocab]

I like the apparent of the current time_this API, at least for single-argument functions. However, I think there's a better API trying to get out.

Timer will take a functools.partial as an argument, but that introduces a lot of timing noise, which is probably not acceptable for this application. Thinking on it.

[mambocab]

One way to deal with the timing noise would be to add a "estimated timing overhead" to the end of each report. All that would be required would be running a noop through the existing timer-running infrastructure.

[mambocab]

Though the existing timing infrastructure finds the minimum runtime. We'd want the... mean? maximum?

[mambocab]

Current thinking on this:

• There should be a base or abstract base class for a Rumble.
• The default implementation should be with partial.
• A secondary implementation can use the string interface. This is basically the current implementation.
• Before each run, the Rumble will run the times on a noop and print the average as an estimated timing overhead

Some caveats:

• I'll have to do some tests to see what that function call overhead for the partial implementation is like.

[mambocab]

The reason the default implementation should be with partial is because it's a much simpler API, especially if there's any setup to be done that involves stuff outside the stdlib.

[mambocab]

With the simplification of the call_with api, I'm leaving this until later.