Rust tests for new compiler

[bspeice]

Companion to kaitai-io/kaitai_struct_compiler#164.

Sets up the the translator and test infrastructure to work better with Rust and the new runtime library. Currently the CI script fails with a parse error in cargo junit (@CWood1 may need to look at that), but cargo test runs just fine.

Right now we're not actually asserting anything (because the compiler isn't actually generating anything), but this at least proves that everything compiles. Getting it to work can be done incrementally, this is a foundation.

[bspeice]

@CWood1 and @GreyCat - Design question for you guys. Right now, Rust uses lifetimes so it can avoid structs having to copy all the bytes off the stream into owned storage. This causes issues with opaque types (meta: ks-opaque-types=true) that may or may not have references (this for example).

I'm going to skip the test for now, but there are a couple potential solutions I can think of:

1. Have structs own their data by copying from the stream into Vec<u8> storage. This allows us to remove the 'stream lifetime, but imposes a runtime cost for allocation and memcpy.
2. A meta attribute for the types involved so that Rust can choose correctly. Requires users to set the attribute in response to compile errors, which may be a pain.
3. Add a PhantomData<&'r ()> marker so that all structs have an associated 'stream lifetime. Because we derive Default, the implementation doesn't change at all, but the API doesn't look as nice.

My preference is towards number 3 (since the point of generating code is to deal with APIs that don't look nice, and Rust should be able to figure things out without needing to be explicit about lifetimes when using generated structs), but figured it was worth getting some input.

[bspeice]

Alright, next issue: even using the PhantomData<&'r ()> to fix the lifetimes, I can't detect opaque classes recursing/owning each other, which is a compile error because Rust can't calculate the struct size. The solution is to insert either an owned reference (Box<>, equivalent to std::unique_ptr), or a plain reference (and then lifetimes become an issue again).

While I'd normally prefer using a plain reference so that I don't need heap allocation, we'd run into an issue because Rust would be unable to establish ownership; the "child" wouldn't be owned by anyone. Instead, I think what can be done is non-opaque user types that don't recurse (the vast majority of cases) are owned by the parent (thus avoiding allocation), while opaque and recursive classes use the heap-allocated boxes because they're unable to establish that it's safe without.

[bspeice]

Next version is available, and tests basic asserts. There's plenty of functionality left to test, but some of it will need support from the compiler before it can be enabled.

The following test cases aren't currently part of the full suite, but should be added later:

• process_coerce_switch: Kaitai resolves this as AnyType, which is illegal in Rust. The actual type is UserType(Foo), but it seems the compiler isn't quite able to figure that out. C++ has issues with this as well, so I don't think it's critical to solve at the moment.
• str_encodings: Rust refuses to compile because of the presence of non-UTF8 symbols in the source code.