handle bank boundary wrapping better for marking operations / in general

[binary1230]

There's a bunch of places in the code where we perform some kind of marking at a particular offset (i.e. marking an instruction and its following opcodes).

However, a lot of these operations, as they increment their offset, cross a bank boundary. While it's not an error since they're still inside the ROM or SNES address space, it's not how a real CPU would interpret it. What we should do is, instead of crossing a bank boundary, we should wrap to the beginning of that bank

Or, stop, tell the user that they're about to wrap a bank boundary and likely, there's been some kind of mistake because it's probable even though the real CPU would do this, that it more likely means there's a disassembly error and they're marking a bunch of stuff as garbage.

---

reference docs: http://www.6502.org/tutorials/65c816opcodes.html#5.1.2
[Note that although the 65C816 has a 24-bit address space, the Program Counter is only a 16-bit register and
the Program Bank Register is a separate (8-bit) register. This means that instruction execution wraps at bank
boundaries. This is true even if the bank boundary occurs in the middle of the instruction.]

affected functions: MarkAsOpcodeAt(), basically anything where we're looping a few bytes start at a particular offset.