Jump Table indexing expected by ghz_fpga_server is confusing

[maffoo]

See the discussion on #324.

The problem is that the jump table indices one has to compute are off by one from the actual indices of command in the list, because the server adds an extra (required) NOP instruction at the beginning. There are a couple of ways to fix this, but we need to decide on the best way and coordinate the rollout between server and clients to maintain compatibility. Possible fixes:

1. require the user to add the NOP, so that then the relative jt indices are consistent (and identical to what goes in fpga memory)
2. OR, add the NOP as here but also add one to jump indices so that when we compute jt indices they point to the right places in our list.

[JulianSKelly]

Thanks for filing this issue, as this clearly rears its ugly head in #324.

I think option 2 is the correct option so we can avoid exposing some hardware details to the user. I think it's fair to let a user assume that sequences start at t=0 and then handle the rest.

Aside: this NOP will be important in implementing paging in the future with the jump table boards. If we have a function thats gonna mess with all the SRAM addresses to do paging, we may as well re-index the jump table entries while we're at it.