New curryable extract - #931

Ok, so I didn't write down what the goal is here. Doing so now.

Meyda has roughly two categories of state it depends on. The first category is the big overarching things that get reused across many buffers of audio, like AudioContext. Generally, one Meyda per audio context seems fine. The user (by which I mean "the developer using meyda") shouldn't need to shuffle their audio context around in their own state, and could do with constructing an object with a reference to it one time and reusing their Meyda object. The second category of dependent state are things that could reasonably change between frames - in a realtime extraction situation the user may need to change which audio features they need, or might need to switch sample rate, or windowing function, number of mel bands, etc.

Rather than using classes and new-ing Meyda, I thought it would be a good idea to write a curried function like this:

Meyda.extract(REUSED_ARGS)(CHANGING_ARGS)(signal);

Of course, directly applying each argument in one call would work fine, or applying the first two and then repeatedly calling the returned function, or providing the changing args each time you provide a signal would be fine too.

I had a lot of trouble getting typescript to display the type signatures of the returned partially applied functions, or the return type of the fully applied function call to be constructed based on the features provided in the changing args.

So the help that I would need here is both:

1. Feedback on the API design.
2. Proposals of alternative API design (something that is "good enough" modern JS without keeping too much state around would be nice)
3. Help getting the Typescript types to line up and have this PR get finished and merged.

Let me know if anyone would like to help on any of those 3 points!

Thanks for the explanation @hughrawlinson! I've mostly used the createMeydaAnalyzer api so I'll have to get a bit more acquainted with things. I think I could help with #3?

Sounds great! The difference between this and createMeydaAnalyzer is that this API can be called from node, or whatever environment, with a signal, and doesn't depend on the Web Audio API. Once this baseline API is working, I'm planning to review the createMeydaAnalyzer API and have it call into the extract API. I'd also review the CLI and have that call extract too. Then, maybe deprecate the original interface, remove it entirely, or rewrite it in a backwards compatible way, haven't really decided yet.