Consider splitting proc state into separate values #548

Currently the state of a proc is a single arbitrarily-typed value. To support multiple state elements, a tuple can be used. However, tuple state is more awkward to manipulate than separate values. One important issue is that tuples unnecessarily couple state values together which makes scheduling complicated.

A motivating example is a proc with two state elements: A and B. The next value can be computed for each state element in one-cycle which theoretically permits an initiation interval of one. However, the state parameter and next state node artificially couple these separate state values together which may make the total latency of the computing both next values together greater than one which prevents an II of 1.

Other potential wins:

• A name may be given for each state value parameter which would persist to Verilog.
• (minor) Identifying and removing invariant state elements is trivial.

Allowing multiple proc state values doesn't fundamentally improve expressiveness. There are ways of working around this coupling issue with extra work in the scheduler and elsewhere. However, it might be much cleaner to allow multiple state values at the cost of a a minorish refactor.