Database organization

[ginty]

Currently the Rust database is organized under one entity, the DUT.

When adding registers recently this proved to make things very tricky when trying to deal with two immutable collections at the same time - adding a new register and the bits for that register.
Ultimately I made it work, but the code could not be organized as I would have wanted it and life would have been much easier if I could have gotten independent references to the register and bit collections.

So the takeaway is that for the global database collections, finer granularity is better, and I plan to transition away from everything under DUT, to having individual collections REGISTERS, BITS, etc.

Pins may already be doing this anyway, and for anything new that is being added by @coreyeng or @pderouen, standalone static variables should be used.

I don't think that should affect the structure of wider code much at all, just a matter of changing the variable you reference, and in many cases these collections are being treated individually anyway rather than the DUT providing some sort of central API - e.g. https://github.com/Origen-SDK/o2/blob/master/rust/origen/src/core/dut.rs#L46

Also bear in mind Rust's interior mutability feature - basically the ability for an object to self modify some of its fields even if it is part of an immutable reference.
I haven't done it yet, but I plan to make the state field of Bit objects like this since they will require to change state a lot and its going to be a whole lot easier being able to deal with multiple immutable register/bit references vs. having to cleanly pass around a single mutable ref.

[coreyeng]

I think if we can get interior mutability to work it'd be cleaner in the long run. Keeping track of and cleaning up statics may be tricky if we start going multi-threaded. And if we're using static variables, we could introduce the static lifecycle again which would allow us to store references to these static variables instead of using an ID lookup table. Not that the lookup table is inefficient, but it is an added layer that could be removed if we use statics.