More sophisticated transaction planner based on multiple constraints

Simplifying a lot, the transaction planner (after #1497) does something like:

For each instruction `i`, for each partially packed transaction `t`, add `i` to `t`. If it compiles to a transaction under the size limit, continue. Else try another `t`. Else create a new message.

The 'if it compiles' part here is now doing a lot of work. If the instruction takes the transaction over 64 accounts, or over 12 signers, or over 64 instructions, then compile will throw.

It's likely that we could write a more optimal algorithm, that can find an instruction that does not violate constraints, by making the planner itself aware of these constraints. This would probably become some variant of a multi-dimensional knapsack problem, with dimensions like number of accounts, number of signers, number of bytes. The goal would be (probably) to minimise the total number of transactions for a given instruction plan.

This is complex because the cost of adding an instruction depends on what is already added. An instruction that uses 20 accounts may add anywhere from 0-20 new accounts to the transaction, depending which accounts are used by existing instructions. This also affects how many bytes it adds, and how many signers. Additionally we must respect the sequential constraints between instructions.

My initial guess is that an algorithm might want to optimise for instructions with shared accounts being packed together as a starting point.