Clarify memory model for transaction queues

[bogdanm]

This is related to pull request #5: there is now a SPI module class which has a transaction queue object. The transaction queue is fixed in size for each instance of the peripheral; currently, there are 16 transactions in the queue for each SPI instance. This seems rather arbitrary and wasteful in terms of RAM. Variants:

1. keep the transaction queue fixed in size, but make the maximum size global per peripheral type, not per peripheral instance (for example: maximum 32 transactions for all SPI instances). Not ideal.
2. make the transaction queue dynamic (new transactions are malloc'd)
3. combine 1 and 2 by starting with a fixed size and growing it only if needed

In the context of this issue, it might be worth investigating if it's worth using some C++ std classes (vector, array ...).

[bremoran]

This seems like a perfect case for a slab allocator. Do we have one?

[0xc0170]

Nope, we don't yet. Let's discuss this topic this week