Limit transactions to 64 instructions

## Motivation

Currently transactions are limited to 1232 bytes, which makes it difficult (maybe impossible but I haven't done the math) to fit more than the permitted 64 instructions. However SIMD-0296 increases this limit to 4096 bytes, without increasing the limit of instructions. Kit should help enforce this instruction limit as much as possible.

We should do this before v1 transactions (which will have the higher size limit), but it can be done independently as the 64 instruction limit is the same for existing transactions, even if they don't/can't hit it. This isn't a new limit for v1 transactions, it's just more relevant/important.

## Details

The places I can think of where we should enforce a limit when working with transaction messages:

- `appendTransactionMessageInstruction(s)` could easily check the new instruction count and throw if >64
- `compileTransactionMessage` could refuse to compile a transaction message with >64 instructions
- Our instruction plan logic should be updated to only create candidate transaction messages with <= 64 instructions, in addition to its existing check on byte length.

Checking a `Transaction` is trickier, because counting the instructions is not trivial in the way checking the length of the message bytes is.

Eg if we wanted to add an instruction count check to `assertIsSendableTransaction`, then this could be inefficient. In the v1 format the number of instructions will be at a known location (3rd byte), but in legacy/v0 it depends on the length of the `accounts` array that comes before it and has a dynamic length, so we'd need to partially decode the message bytes.

In most cases this wouldn't be needed though, because we could have `compileTransactionMessage` (and modifying signers) include a type indicating eg `TransactionWithinInstructionLimit`, if it checks the instruction count as mentioned above.