AutoZNG implementation using builtin rust tooling

[nate-fe2o3]

This implementation targets the direct, automatic creation of the ZngurSpec object from info derived from several rust tools:

• Crate API (types, functions, methods, traits, impl blocks, etc.) generated by the rustdoc_json crate (wrapper around cargo rustdoc) and then deserialized into a Crate object by the rustdoc_types crate.
• Memory Layout info using rustc's print-type-sizes nightly feature
• Rust std/core dependency support using the same strategies on statically included json files

The bulk of the work is in the new zngur-def/rdoc.rs file that contains an (incomplete) translation layer from the rustdoc Crate type to the ZngurSpec type. Several types aren't yet supported, but work is ongoing. Standard library dependencies are noted on the first pass of the translation, and then added to the ZngurSpec on separate passes of the RustDocParser.

[nate-fe2o3]

I tried my best not to touch any existing code other than adding the --auto implementation for the cli. Some notable changes to existing code other than that are the From<Primitive> and From<String> impl blocks for PrimitiveRustType in zngur-def/lib.rs, as well as marking some types in the examples as public.

[nate-fe2o3]

The current implementation is stuck on the rust std/core dependency resolution, where it hits unimplemented functionality in zngur-generator/rust.rs. I've been running this against the tutorial example, and the particular issue happens when parsing methods for Vec and ends up calling into_cpp() on a RustType::Raw.

[HKalbasi]

Thanks for the PR! I think the auto generation of zng files is the most important remaining thing for zngur.

There are some challenges for auto generating the zngur file, I also mentioned some of them in #5:

1. We don't know which instantiation of templates the user need. They may need Option<Result<Vec<i32>, SomeError>>, but auto generating every possible type takes infinite amount of code. This is not only a problem for types, but also a problem for generic methods, methods taking an impl Trait, ...
2. Generating massive amounts of code makes compile time of the C++ side super slow, specially since the codes are mostly headers / templates. Now that you have the code, we can measure it empirically (I'm really interested in the number of lines needed for std in generated.h), but I guess we can never afford to generate bridge for the whole std or other libraries with a big surface.
3. There is a similar problem with trait implementations. I guess rustdoc may help us in this, but otherwise we have no way to include methods of traits on types.

Due to these challenges, I think fully auto generating the zng file is impossible, and we need to change the zng file or introducing another auto-zng file to enable the user to select the type, methods and instantiations they need. That file ideally should support a glob-like syntax (e.g. I want all methods for this type, or I want Vector of all types in this crate). It should also try to deduce when something is needed instead of requiring explicit annotations, e.g. when Vec<i32>::first is generated, it should automatically add Option<&i32> which is its return type. The --auto added in this PR could be a simple query for generating all non generic types inside a crate in the autozng file.

[HKalbasi]

where it hits unimplemented functionality in zngur-generator/rust.rs.

I added raw pointers support so we can now continue testing the current implementation.

[nate-fe2o3]

Thank you! I've been thinking through the problems you mentioned with the naive auto-generated approach and am doing more research. Will keep you posted on how it turns out.