Traits abstracting backends

Although all database backends used are very similar, they have some crucial differences in small implementation details that must be worked around when conforming them to cuprate_database's traits.

Put simply: using cuprate_database's traits is less efficient and more awkward than using the backend directly.

For example:

• Data types must be wrapped in compatibility layers when they otherwise wouldn't be
• There are types that only apply to a specific backend, but are visible to all
• There are extra layers of abstraction to smoothen the differences between all backends
• Existing functionality of backends must be taken away, as it isn't supported in the others

This is a tradeoff that cuprate_database takes, as:

• The backend itself is usually not the source of bottlenecks in the greater system, as such, small inefficiencies are OK
• None of the lost functionality is crucial for operation
• The ability to use, test, and swap between multiple database backends is worth it