Properly support tuple field accessors typing

[LPTK]

There are currently at least two ways in which they are broken:

1. While they work on simple types thanks to the case in ConstraintSolver:

   t = (1, 2, 3)
   //│ t: (1, 2, 3,)
   //│  = [ 1, 2, 3 ]
   
   t._1
   //│ res: 1
   //│    = undefined

   they don't work for more complex cases, because the normal forms don't know about them:

   t = (1, 2, 3) with {x = 1}
   // t = (1, 2, 3)
   //│ t: (1, 2, 3,) & {x: 1}
   //│  = Array { '0': 1, '1': 2, '2': 3, x: 1 }
   
   t._1
   //│ ╔══[ERROR] Type mismatch in field selection:
   //│ ║  l.301: 	t._1
   //│ ║         	^^^^
   //│ ╟── expression of type `(1, 2, 3,) & {x: 1}` does not match type `{_1: ?a}`
   //│ ║  l.294: 	t = (1, 2, 3) with {x = 1}
   //│ ║         	     ^^^^^^^^^^^^^^^^^^^^^
   //│ ╟── but it flows into reference with expected type `{_1: ?a}`
   //│ ║  l.301: 	t._1
   //│ ╙──       	^

2. We can subvert them, causing a soundness problem:

   t = (1, 2, 3) with {_1 = "oops"}
   //│ t: (1, 2, 3,) & {_1: "oops"}
   //│  = Array { '0': 1, '1': 2, '2': 3, _1: 'oops' }
   
   (t: (int,int,int,))._1
   //│ res: int
   //│    = 'oops'

[LPTK]

Related JS-gen issue: #65 (comment)

[LPTK]

I realize the right way of doing this is to change the way field removal types act on tuples (and arrays).

Currently it leaves tuples untouched:

mlscript/shared/src/main/scala/mlscript/TyperHelpers.scala

Line 318 in b15b776

case t @ TupleType(fs) => t

mlscript/shared/src/main/scala/mlscript/TyperHelpers.scala

Line 358 in b15b776

case _: TypeVariable | _: ClassTag | _: RecordType => rw

We should add a field in TupleType and ArrayType to remember which fields have been hidden by a Without type applied on such types.

(Cc @Meowcolm024.)

[LPTK]

Another improvement request: properly reason about intersected tuple-record types, as mentioned in #79 (comment).

For example:

def test: (string, 1) & { _1: "hello" }
//│ test: (string, 1,) & {_1: "hello", _2: 1}

The above should simplify to test: ("hello", 1,).

Moreover in:

test: { _1: 'a }
//│ res: {_1: "hello"}

test: ('a, 1)
//│ res: (string, 1,)

I would have expected to get type ("hello", 1,) for the latter.

Similarly, the following could "simplify" to res: Array[1] & {_1: 1}:

error: Array[1] & { _1: int }
//│ res: Array[1] & {_1: int}

[LPTK]

I realize the right way of doing this is to change the way field removal types act on tuples (and arrays).

Note: To make things simpler, we didn't go with this approach. Instead, we just convert these types to records upon removing fields from them, which is not optimal ((1, 2) with {_1 = 3} is typed as {_1: 3, _2: 2} whereas it could be typed as (3, 2)), but probably sufficient for now.