Todo (dev docs): describe scalability

[harding]

@petertodd recently mentioned that the dev docs doesn't mention anything about scalability, but that we should so that startups don't get the wrong idea about on-chain growth potential.

I think mentioning scalability would be a good thing, but I also think we should only briefly mention it. Given our audience description of application programmers, not Bitcoin system designers, I think these are the salient points:

1. The current block size max is 1 MB. (We do already mention this but in technical data section.)
2. Changing the max block size requires a hard fork, which at the very least requires discussion and (with high probability) a multi-month deployment time. At the most, a hard fork changing the block size may be rejected either in discussion or by a sufficient number of network participants.
3. Miners choose what transactions to include and how many of them to include. Even if more block space is available, it is not guaranteed that miners will fill them with transactions from the queue.
4. The hash rate majority may decrease the currently allowed size of blocks at any time using a soft fork.
5. Every unconfirmed transaction competes with every other unconfirmed transaction for block space.

In short, developers (and business plan writers) should not assume future transactions will be as easy or as cheap to confirm as current transactions.

Is there anything important that I missed, or an alternative approach that I should take?