Proposal: Removing limitations of Tuples, by adding reference tuples and generating custom tuple types

**Reference tuple types**
I have been using tuples with Preview 5, and lack of reference types is particularly striking. With ValueTuple as structure, I can't use tuples for mutable lists or dictionaries.

```
Dim l = new List(Of (X As Integer, Y As Integer)
l.Add((1,1))
l(0).X = 2 ' compiler error, member of structure can't be modified
```

Replacing whole tuple

`l(0) = (2, l(0).Y)`

is very unpractical, and nobody will update lists that way, especially with higher number of tuple's members.

For now I have solved this problem by creating my own library with tuples identical to those in your library posted on nuget, except that ValueTuple types are classes instead of structures. After referencing this library to the app, tuples in lists can be mutable.

I suggest to add another set of tuple types to the library that you created and posted on nuget. New tuple types will be classes with another name (for example ReferenceTuple). To specify that reference tuples must be used, there must be added entry in AssemblyInfo,

``

(BTW:
If external library with tuples is not referenced by app, then compiler error says that 'ValueTuple must be defined or imported'. How to define these ValueTuple in my app code, if I do not want to use external library ? Docs do not state how to do it.
)

**Custom generated types for tuples.**
Tuples using ValueTuple are not suitable for reflection scenarios (databinding, serialization and others), because these scenarios require original names of members. These limitations can be removed, when tuples will be handled by compiler generated custom types, instead of ValueTuple types.

Custom types for tuples are enhancement, not replacement, so user may decide which model is used across assembly / app, by adding entry to AssemblyInfo

``

There is need that names of compiler generated types must be deterministic, because serialization requires that behaviour to operate correctly. For example for tuple:

`Dim t = (A:=0, B:=(C:="abc", D:=0))`

name may be like VT_A_INT_B_TUPLE2_C_STRING_D_INT (prefix VT_ means value type, while RT_ means reference type, if TupleReferenceTypes(True) is specified for app/library). Such name is too long, so may be hashed to shorter variant, and final name for custom type is Tuple_7654567. Such generated names are bit cryptic, but they are only used to carry data, and with widespread use of type inference, this won't be problematic.

These custom types must be unique across assemblies,and this may be achieved in some special way. Custom types won't be included into app/library, but into external assembly with fixed name (for example TupleCustomTypes.dll). This external assembly will be automatically created and updated by compiler. App/library will get only metadata which describe custom types that are used internally, and these types will be referenced from external assembly (TupleCustomTypes.dll). When some library with metadata will be referenced by project, then compiler will read these metadata, and update external assembly (TupleCustomTypes.dll). For backward compatibility with previous compilers, external assembly must be shipped with library. There also may be created external tool, that generate single external assembly, from multiple libraries with metadata.

These two enhancements, will make tuples really shining and universally accessible for much many scenarios, than currently.