Refactor analysis into active/reactive subclasses of `FoaEval`

[mtmccrea]

Not a big issue, but I noticed that FOA analysis Ugens related to the reactive intensity include the method argument. As the docs helpfully point out, reactive metrics aren't supported for the 'average' method, so there is currently only one valid method:'instant'.

As instant is the default argument, a user can simply omit it, but perhaps a cleaner solution is to omit the method argument altogether for those metrics involving reactive intensity. One approach is to subclass FoaEval into FoaEvalActive and FoaEvalReactive, for example. (Not having thought through it much, there could be another approach.)

This is of course moot if the intention is to add more analysis methods in the future, or if the arg is there for pedagogical purposes...

[joslloand]

This is worth thinking about, but maybe within a context of a larger refactor of FOA analysis (Though I can't find it, this is related to a style conversation I was having earlier with @telephon, so, @mtmccrea , you're not the only one.)

Maybe more as a note to self, the (pedagogic) intention was to bring instantaneous and time averaged analysis into one user facing interface. Part of this had to do with my frustration with the literature, where authors often seem unaware that there are two time domain analyses that are possible.

As a tangent, we can also run the analyses in the frequency domain. And, for a full featured ATK, I'd like to include some form of these:

1. sclang: Signal extensions
2. scsynth: PV_ChainUGen pseudo-UGens

The sclang methods will be addressed first, as these should be straightforward.

I'm a bit vague regarding the scsynth side, having not spent any time reviewing whether we'll easily be able to do what needs to be done. The scsynth side (using PV_ChainUGen, or not) involves some consideration as to how exactly to return results: time or frequency domain, or both? And how best to manage that.

So... at this exact moment, I'm feeling that addressing any scsynth / PV_ChainUGen pseudo-UGens solution would be a good time to reconsider analysis.