Allow users to control access level of fields in generated types

[randomPoison]

Currently for any fields that are marshaled by value, the fields in the generated C# struct are always public. Right now that's necessary otherwise it would be impossible to meaningfully use those types, however this is a restrictive design means that cs-bindgen doesn't support a number of common use cases. For example, for newtype structs it's often desirable to keep the inner value private and control how values of that type are created (which currently can't be enforced on the C# side).

It would be reasonable to set the default access level of fields based on the access level of the corresponding Rust field, along with additional attributes to tweak the generated C# code where needed.

The main issue with doing this right now we don't track access modifiers in the exported type data, so that information isn't available to the C# code generation logic. The access modifiers are readily available to the cs_bindgen proc macro, however from a design perspective it's not clear how to best expose that information to the C# code generator.

Currently, all information about fields is handled by schematic. However, it seems inappropriate to have schematic expose information about access level for fields for a couple reasons:

• Schematic is intended to describe data, rather than fully provide all metadata about Rust types. Access modifiers don't show up in data, so it seems inappropriate to include them in the describe information.
• Schematic tries to follow Serde's conventions as much as possible, with the specific goal of describing the schema for data generated by Serde. Serde doesn't care about access modifiers (public and private fields are serialized the same), so it seems like schematic shouldn't either.

However, including field access levels in cs-bindgen-shared also seems problematic:

• Information about a field ends up split up in two places: Type data in the schema generated by schematic, and additional "metadata" tracked directly in the NamedType.
• We currently unify structs and enums as "named types" in cs-bindgen-shared, however access modifiers and other field metadata act differently for structs and enums. The main difference is that enums have variants that in turn contain fields, whereas structs just have fields. Including field metadata in the NamedType could result in a cumbersome API that makes the C# code generation logic unnecessarily complex.

Some additional design work will be needed here in order to figure out the right way to handle access modifiers. This also relates to the more general question of how we apply custom attributes to fields and enum variants, so it might be good to split that question off into its own ticket.

[randomPoison]

Now that we're planning on removing the dependency on schematic (#59), the original design questions around tracking field metadata are effectively resolved. Specifically, once we have our own way of describing custom types in cs-bindgen, we can add any additional metadata like visibility to it.