rework Instrument API to allow efficient implementation

[njsmith]

The Instrument API potentially adds overhead, since we have to call the hooks at all kinds of low level places that might be happening in tight loops. I'm not really worried about the overhead right now, but we should make sure that if we do decide to optimize it in the future, that we won't have to break the API to do so.

I think there are two parts to this:

• Instead of blindly letting users muck around with the list of instruments, provide some explicit API for mutations. This is crucial because it lets us preprocess the list.

• Make sure that we can tell by examining an Instrument object which hooks it actually provides. This way our preprocessing can tell things like "there are no Instruments registered for this event, don't even bother looking".

[njsmith]

Regarding introspecting the instrument object to tell which hooks it provides: I think it's sufficient to detect either (a) the method is undefined, or (b) the method is inherited from the do-nothing trio.abc.Instrument class. These are both easy to detect and should cover all the cases that are likely to come up. We might need to note that like you shouldn't define a do-nothing method for no reason, but I doubt many people will need that advice.

[njsmith]

After we kill current_instruments, think about this: #47 (comment)