csr: A proposal for DSL design

[ghost]

This pull request was based on the initial design (3195de9) here on M-Lab's repo, so its usage might be different from the more recent nmigen-soc branch on nMigen's repo and the syntax might be incompatible with that. The main focus of this PR is to introduce a domain-specific language (DSL) subset of nMigen just for implementing CSRs. Below shown is an example showing possible ways to declare a hierarchy of CSRs:

with Bank("decoder_bank", addr_width=5, data_width=8, alignment=2, type="dec") as bank:
    bank.r += [
        Register("read_only", "r", width=8,
                 fields=[Field("val", width=8, reset_value=0x22)])
    ]
    with Register("read_write", "rw", width=16) as csr_rw:
        csr.f += [
            Field("ro", access="r", width=5, reset_value=0x16),
            Field("wo", access="w", width=4, reset_value=0x3),
            Field("rw", width=7, reset_value=0x4c,
                  enums=[("MIN", 0), ("MAX", 0x7F)]),
        ]
    with Register("write_only", "w") as csr_w:
        with Field("val", width=2, startbit=2, reset_value=0x4) as field_val:
            field_val.e += [
                ("EXTREME_HIGH", 3), ("HIGH", 2),
                ("EXTREME_LOW", 0), ("LOW", 1)
            ]
        csr_w.f += field_val
    bank.r += [csr_rw, csr_w]

Its equivalent CSR design can be described with the following picture:

Another main change to the existing code in the master branch here is a fix on WishboneCSRBridge such that the Wishbone ACK can be asserted properly per read or write.

---

To-do / Possible improvement

1. Bitmasked Enums: As per discussion, an enum value could be a "bitmask" where certain bits are "don't care", as in the SVD format. One concern is that whether or not each bitmask value should have a unique name as the key.
2. Re-test using latest CSR bus definitions: By simulation and preferably on an actual platform as well.
3. @property tags: Currently they are here to prevent users from editing the values after instantiating the CSR fields as their Signals are named the same way. Is this necessary?
4. Automatic address width: Is it possible to assign/re-assign the address width for the register and bank dynamically as the user adds more fields or registers to them?