RFC: split primitive datatypes and their high-level implementations #5458

Submitting this now because I'd like to see if it's a workable concept before continuing. I started by adding the structures from primitives/* because they were the most obvious target. No need to bother reviewing the changes in detail, I'm just looking for some concept ACK/NACKs.

The goal here is to separate the definitions and serializations of basic core structures from their higher-level features. My primary motivation at the moment revolves around making future library work easier. With the definitions/serializations separated, many of bitcoind's dependencies melt away.

Another nice benefit is that base.h becomes rather self-documenting for the wire format. A bit of doxy there would go a long way.

High-level classes inherit from the newly separated low-level ones. The base classes provide only constructors and (de)serialization. Templates are used as a bit of nested trickery, so that high-level classes can continue to stack on top of each-other.

@sipa I've seen you discuss the idea of very bare base classes before, is this similar to what you had in mind?

I was more thinking about just stripping all non-trivial features off of classes in base/*, and moving them up to application code as functions. Things like SetNull and IsNull are low-level enough IMHO, but anything that forces more dependencies or has validation logic in, doesn't belong there.

Specifically, I think uint256 should be separated into a bytes32 type or something which is just storage (but does have comparison operators, so it can be used as key in a map), but doesn't have any arithmetic logic.