Switch slicing procedures to take int64 indices

This has two major benefits:

- We can consistently raise a range-error? when being passed a negative
  or large index. Right now we will raise a type-error? if we can
  statically determine it's negative or truncate otherwise. We should be
  checking integer ranges before truncating but in this case we're
  checking the indices anyway so we can simply do it at their full 64bit
  size

- This will make it easier to support 64bit lengthed bytevectors on
  64bit platforms.

This also adds missing functional tests for some ranged procedures. In
particular, (bytevector-copy) wasn't validating its range at all and is
fixed to call assertSliceValid as part of this work.
Clean up (*-set!) and (*-ref)

- Use 64bit indices for consistency with the slicing procedures and to
  support large vectors and bytevectors

- Add assertIndexValid helper function to both Scala and C++ to produce
  better error messages which include the object length and requested
  index

- Add functional tests for -set!/-ref with negatives indices
runtime: Fix incorrect assert message

The comment was updated for the inline symbol changes but the assert
message was not
64bit vector/bytevector support and cleanups

This allows vectors up to the size of the virtual address space and
bytevectors of 2^63-1 bytes on 64bit or the size the address space on
32bit.

- Introduce type aliases for our various length types and add
  ::maximumLength() for strings, symbols, vectors and bytevectors. These
  are based on the underlying storage types for the values.

- Introduce RecordLikeCell::RecordClassIdType to abstract away the types
  of record class IDs

- Rename SharedByteArray::refcount_t to SharedByteArray::RefCountType
  for consistency

- Add assertLengthValid() which is analogous to assertIndexValid
  except for validating the length of new objects

- Add adjustSlice() to factor out the slice adjustment logic from
  strings, vectors and bytevectors

- Change llcore_vector_elements_alloc to llcore_vector_alloc which will
  allocate both the vector cell and elements at once. This is required
  to properly handle exceptions when the length is loo targe and in the
  future when out-of-memory errors are supported

- Update cellTypes.celldef and the various stdlib functions to use 64bit
  lengths for vectors and bytevectors
Add out-of-memory-error?

This is currently only raised by (make-vector) and (make-bytevector) as
they're the easiest ways to indirectly allocate nearly unbounded memory

Unfortunately this can't be reliably tested as every machine has a
different memory limit and many OS configurations will simple kill
processes that exceed it.
compiler: Fix typo

operamds => operands