Add pad_jmps nop support for trace building

This was PR 215179/Case 10744.

Today with -pad_jmps_shift_bb we avoid inserting nops before exit cti to keep cti offsets from crossing cache lines (and thus keeping them atomically patchable). This works great for regular bb's. However, with client changes to a bb, or significant internal mangling such as for rseq (#2350 (closed)) or even just for UNIX inlined syscall fence exits, we can have extra exit cti's such that a single shift does not always work. We then insert nops in front of jumps, but we never added trace building support for these nops: we need to distinguish them from app code or client-inserted instructions in decode_fragment. So we mark as FRAG_CANNOT_BE_TRACE when we add a nop.

This cannot-be-trace is problematic: we can have a bb with no nops whose temp private copy for trace building needs nops (just due to fcache start alignment) and end up not making forward progress building a trace.

There are comments about this in the code labeled "PR 215179". I'm filing this in the current tracker to ensure we can more easily track and address this issue.