Add support for enum/error fields from tuples

[bendk]

Currently, enum/error with fields require the variant to use named fields. Take the example from the book:

Rust:

enum IpAddr {
  V4 {q1: u8, q2: u8, q3: u8, q4: u8},
  V6 {addr: String},
}

UDL:

[Enum]
interface IpAddr {
  V4(u8 q1, u8 q2, u8 q3, u8 q4);
  V6(string addr);
};

But sometimes the tuple style is much more convenient and feels more Rust-like. It would be nice to support that too. What if we added support for these via a UDL annotation?:

Rust:

enum IpAddr {
  V4(u8, u8, u8, u8),
  V6(String),
}

UDL:

[Enum]
[TupleFields]
interface IpAddr {
  V4(u8 q1, u8 q2, u8 q3, u8 q4);
  V6(string addr);
};

Here's how I'm thinking [TupleFields] could work:

• It can be applied to either a single variant, or the enum/error as a whole. Annotating the whole enum/error is like annotating each variant.
• For the scaffolding code, if a variant has [TupleFields] applied, then we use the index of the parameter rather than the name to get the field value (ipaddr.0 instead of ipaddr.q1 in the above example)
• For the bindings code, we still use named fields.
• The [StructFields] annotation would undo [TupleFields]. This is useful for when the entire enum/error is annotated. We could also consider switching which one of these is the default.

┆Issue is synchronized with this Jira Task ┆Issue Number: UNIFFI-103

[tnull]

Support for tuple variants would be really nice to have!

In fact, it's currently the last thing that is blocking a UniFFI-based project we'd like to work on, as it would currently would force us to introduce many newtypes around Rust enums featuring tuple variants coming from an upstream library (i.e., where we can't influence/change the enums to use named fields).

[mhammond]

For the bindings code, we still use named fields.

I'm not quite convinced about that part yet.