Re-evaluate use of `index`; look into a proper host/device size type.

`index` is not the appropriate type for byte offsets/lengths as it's treated as signed (which introduces a ton of risky pointer arithmetic) and it assumes that it is the same bit width everywhere (host/device). Instead we should model all our offsets/lengths with a `!util.host_index` and `!util.device_index` - or go even further to `!util.host_offset`/`_size` and `!util.device_offset`/`_size`. C has things like `size_t`/`ssize_t`/`ptrdiff_t`/etc for a reason and today we're aliasing all those to `index`.

We should treat `index` as passed in from the frontends as a user-defined width used just for indexing/defining tensors - then users can specify that they want 32 or 64 bit tensor dims independently from their target hardware register/address space sizes. When we insert our own index types (mostly during flow->stream and stream->hal) we can use our own appropriate types.

This also means getting out of `arith` for pointer manipulation which would be a really good thing. Pointers are not integers and the semantics we want on them (especially if we care about safety) are very different. A limited set of operations on with defined semantics for overflow/wrapping/etc would be ideal as then we can route them through safe math lowerings (we want either saturating or failing behavior such as in things like https://github.com/chromium/chromium/tree/master/base/numerics / https://github.com/dcleblanc/SafeInt/blob/master/SafeInt.hpp / https://docs.microsoft.com/en-us/cpp/safeint/safeint-library?view=msvc-170). Converting between host <-> device <-> ints should never allow for invalid offsets/lengths to be generated.

We of course would want this in codegen too - but there's not much I can do about that given how upstream it all is.

Major tasks:
* [ ] Define the new types with a common interface.
* [ ] Define a new dialect/set of ops with safe operations on the types.
* [ ] Switch stream/hal/vm dialects to generating these types.