3C handles itype_for_any generics by overconstraining

[kyleheadley]

This issue summarizes the current status of generics processing, with the current limitations.

For single pointer generics like the malloc'ing an array for ints, 3C handles as we want it to. This is the most common case.

For pointers of greater depth, 3C over-constrains the generic parameter, requiring all callers to match. See type_params_xfail1.c. This has been seen in our BC benchmark, see #427 (the solution to the issue dealt with the merger instead of the generics).

As explained in #427, the new constraints are added when code execution reaches this point which allows size differences in Cvars if one is generic. It handles it with calls to getAtom which adds an atom when one more is requested of a generic than are available.

There is an open issue (#358) for adding more support for rewriting void* into itype_for_any. It goes on to suggest additional improvements but ultimately leaves open the question of how to handle over-constraint.

A fuller solution would likely involve context-sensitive constraints, that is, a set of constraints per function call, and multiple FVComponentVariable::InternalConstraints to match them.

[kyleheadley]

This is centered around the extra atoms, which were removed in #655. #358 is still the active roadmap for continuing work in generics.