--------------------------------------------------------------------------------
Field storage / next value layer
--------------------------------------------------------------------------------
Where all the magic happens!!

Any field that implements storage is defined here.
Bigass struct that only contains storage elements

Each field consists of:
    - an always_comb block:
        - generates the "next value" combinational signal
        - May generate other intermediate strobes?
            incr/decr?
        - series of if/else statements that assign the next value in the storage element
            Think of this as a flat list of "next state" conditons, ranked by their precedence as follows:
                - reset
                    Actually, handle this in the always_ff
                - sw access (if sw precedence)
                    - onread/onwrite
                - hw access
                    - Counter
                        beware of clear events and incr/decr events happening simultaneously
                    - next
                    - etc
                - sw access (if hw precedence)
                    - onread/onwrite
        - always_comb block to also generate write-enable strobes for the actual
          storage element
          This is better for low-power design
    - an always_ff block
        Implements the actual storage element
        Also a tidy place to abstract the specifics of activehigh/activelow field reset
        selection.

TODO:
    Scour the RDL spec.
    Does this "next state" precedence model hold true in all situations?

TODO:
    Think about user-extensibility
    Provide a mechanism for users to extend/override field behavior

TODO:
    Does the endinness the user sets matter anywhere?

Implementation
    Makes sense to use a listener class

Be sure to skip alias registers