The future of ComposerType

[codygunton]

I took these notes on ComposerType's uses prior to undertaking the work of #296 and #326 .

ComposerType Uses:

A fuzzer constants 
X passed to compute_proving_key_base (garbage)
X join_split_example templates by `ComposerType` (bad form but good interface?)
F Used by benchmark collector
X used to set `SYSTEM_COMPOSER`
X used to set `MAX_NUM_SIMULTANEOUS_FFTS` in polynomial cache
`F`/X used to construt polynomial manifest
A specify context for constructing circuits in stdlib
F specify proving system against which to test circuits in stdlib.
A constexpr branches in stdlib (== and !=)
  - generically when we want to use tables
  - specifies curve type in ecdsa
  - different pedersen algs
  - misused in `secp256k1_ecdsa_mul`(?)

I coded this like:A for "this belongs in arithmetization", F for "this belongs in proving system flavor", and X for "this could or should go away". I believe there is another use which is new since I wrote these notes, namely, ComposerType is used as a numerical identifier to make the verification key depend on the proving system type.

I believe we should split up the ComposerType abstraction as appropriate. For instance, if we want the data put in the vk hash to be as granular as possible, then perhaps ComposerType should be FlavorID. On the other end of the spectrum, it should simply become something like ArithmetizationID.

As for how to specify which code paths to use in the stdlib, I suggest using C++20 concepts as outlined here or perhaps using the approach here. Either one lets us avoid ever-more-complicated constexpr logical expressions in the stdlib.