Adding &[u8] support.

[adetaylor]

This change adds specifically, support for &[u8] with a corresponding
rust::Slice<uint8_t> type. No other types of slice are permitted. The
rationale is that it may be common to pass binary data back and forth
across the FFI boundary, so it's more urgent to get this in place sooner.
Broader support for other slices can wait for the future.

But, both C++ and Rust-side bindings should allow the existing support
to be broadened to other Slice types in future without code changes.

A few specific notes:

• The name rust::Slice might be better as rust::SliceRef but I'm
  following the precedent of rust::Str.
• It would be good to add constructors from std::span but as that's
  a C++20 feature, that may have to wait until C++ feature detection
  is resolved. Meanwhile, rust::Slice<uint8_t> can be constructed
  from a raw pointer and a length.
• Internally, this follows the pattern of &str, where the parser will
  initially recognize this as Type::Ref (of Type::Slice) but then
  will replace that with Type::SliceRefU8. Type::Slice should not
  persist through later stages. As we later come to support other
  types of slice, we would probably want to remove Type::SliceRefU8.

[dtolnay]

Thanks -- my work codebase just needed the same thing yesterday. Will review ASAP. In the meantime, it looks like the Bazel, Buck, and Windows builds are all failing with the same error:

function tests$cxxbridge02$c_try_return_sliceu8: error: undefined reference to 'tests::c_try_return_sliceu8(rust::cxxbridge02::Slice<unsigned char>)

Would you be able to take a look?

[adetaylor]

Yes, I'll take a look - but probably not for ~ 3 hours due to meetings. (My day job, sigh :) )

[programmerjake]

for C++ feature detection, the following should work:
https://gcc.godbolt.org/z/tkMZqM

#ifdef __has_include
#if __has_include(<version>)
#include <version>
#endif
#endif

#if __cpp_lib_span >= 202002L
#include <span>
void has_span(std::span<char>) {}
#endif

[adetaylor]

@programmerjake Thanks for that suggestion. There's some discussion on feature detection over here - #80 - which is why I didn't attempt to do it on this PR.

[dtolnay]

This is great. I am still eager to support &[T] in general but it's great to start with this, and this approach is forward compatible with supporting slices in general later, as you observed.