Support for ByteArray operations

I recently came up with some [custom constructs for `readByteArray`, `writeByteArray`, and `indexByteArray`](https://github.com/andrewthad/posix-api/blob/26bd2c408d672cec988f4d2fc935473f4baceb3a/include/custom.h) while working on `posix-api` and `ping`. These are mostly complete. They are still missing some of cases for C field sizes that I haven't happened to use yet.

I've been doing some work the last few days to reduce allocations in the event manager in `base`. The results have been excellent so far (it's like a jungle full of low-hanging fruit), but I ran into a problem today. I've copied some of the machinery from `primitive` into `base` so that I can use it in the event manager. And I needed my `custom.h` file. But it doesn't work. I get this failure:

directive "index" is not safe for cross-compilation

This error is completely accurate. The readme for `hsc2hs` makes it clear that custom constructs are not supported when cross-compiling. But `base` seems to have a policy that cross-compilation must be possible (an understandable perspective). So, I'd like to add support for these to `hsc2hs` itself. Then it should be possible to use them without interfering with cross-compilation. And then I can use them in `base`.

Specifically, what I would like to add is the following constructs, which expand into the things on the right (note that `OFFSET` means the offset divided by the size of that field):

```
#{index struct foo, myfield} ==> \arr -> indexByteArray arr OFFSET
#{read struct foo, myfield} ==> \arr -> readByteArray arr OFFSET
#{write struct foo, myfield} ==> \arr v -> writeByteArray arr OFFSET v
```

Additionally, it would be really convenient to also have available:

```
#{read# struct foo, myfield} ==> \arr s -> readByteArray# arr OFFSET s
#{write# struct foo, myfield} ==> \arr v s -> writeByteArray# arr OFFSET v s
```

These last two variants are helpful when writing `Prim` instances for data types corresponding to C structs with multiple fields. It's possible to get by with just the first three constructs, but these last two help keep things concise when you're working with state tokens directly.

I'm happy to figure out how to implement this. Let me know if this is in-scope for `hsc2hs`.