Limit size of generated machine code to allow more efficient branching.

[markshannon]

Most architectures have smaller and more efficient ways of branching to "near" locations than "far" locations.

In x86-64 a branch to a location within 2GB is smaller than to an arbitrary 64 bit location.
Likewise, in AArch64, a branch to within 1MB is a single instruction, but further branches will take more instructions.

We should limit the size of traces such that we can use more efficient branches in the generated machine code.

This will have little or no impact, as traces in release builds are unlikely to ever reach this limit, but we will to need enforce it for correctness, especially in debug builds.

[markshannon]

I don't know if it is worth having a runtime check for this, or whether we are better limiting the number of uops in a trace so that the size of machine code cannot exceed the limit.

Refactoring out the body of the largest uops into functions might be sufficient to keep the size down.

For example, CALL_KW_NON_PY is the uop that generates the most machine code, 700+ bytes normally but over 3.5k bytes in a debug build. It could easily be factored into a small uop and helper function.