[Bug] Review/fix generated traits for complex types

[ma2bd]

🐛 Bug

In Java, TupleArray<T, N> currently translates to a Java array T[] (omitting annotations). Sadly, Java arrays don't have the expected "value" semantics when it comes to equals() and hashCode(). This is an issue for users who rely on equals() for every type T1 that contains a TupleArray<T, N>. This also prevent Java instances of Map<T1, T2> from working correctly for such type T1. Note that the same issue was the reason for Bytes to use a wrapper class around byte[] in Java.

In general, for each language, we need to make sure every Serde type is either fully supported or disallowed. Disallowed types (if any) should fail codegen.

[ma2bd]

#73 takes a first stab at this issue by fixing equality for (supported) Serde values.

• Some "complex" Serde types such as Map<Foo, T> are still not supported in every language (e.g. Rust and C++, for different reasons).
• Maps as keys (Map<Map<T1, T2>, T>) is not supported yet. It may not be feasible in all languages. We will see.
• Using Floats (or types containing floats) as keys will always be problematic because NaN != NaN (in fact Rust does not let us derive Eq or Ord for floats in the first place).