Make type annotations to not propagate through merging

[yannham]

First step toward fixing #1228. Make type annotations behave differently from contract annotations, and in particular, make them not propagate through merging.

Content

This PR makes a distinction between the contracts coming from a type annotation and the one derived from a contract annotation. In particular, the former aren't stored lazily inside the pending contracts of record fields, nor are they propagated through merging anymore. The contract application for a type annotation is generated statically during program transformations once and for all, making such contract checks local.

Conversion from a record type literal

Doing so, we encountered an interesting issue, which was that the following program was accepted:

let C = {foo : Number} in
{foo = "a"} | C

Here, {foo : Number} was parsed (on current master) as a record literal with one field and without a definition. But because record contract application is mostly merging, the type annotation {foo : Number} isn't propagated anymore.

But if we write

{foo = "a"} | {foo : Number}

Then it do report a contract violation, because {foo : Number} is now considered first as a record type, then converted to a proper contract (not a record contract, but a builtin special function), and applied correctly.

It turns out this is a discrepancy already present on master, and {foo : Number} qualifies as a record type but is only considered so in a type position. It's just that on master, the difference between the interpretation as a record type and as a record literal is much less noticeable (but still here: for example, record type contracts currently kill metadata, it's a bug, but this is nonetheless an observable distinction between the first and the second example already on master).

This PR makes a record literal qualifying as a record type to be always interpreted as such, even in a term position. As an illustration:

nickel> {foo : Num}
<func>

We get an opaque function instead of a record. I think it's mostly fine, because it doesn't make much sense to apply record operations such as merging on such an object anyway. It can be considered the same as Number -> {_ : String}, that is some opaque value that can only be applied as a contract.

The typed field without definition restriction

After the change, something like {foo : Number, bar | String} can be misleading. It's not a record type, so we have the same behavior as the initial problematic example, which is that when used as a contract this expression will never enforce that foo is a number (but it will enforce that bar is a String). Because a freestanding type annotation on a field without a definition doesn't make much sense (after the current change, they are useless, and can be removed to exactly the same effect, because they don't apply to any expression), we simply make them illegal at the parsing stage. That is, you must either write a record type, or you can't write a field with a type annotation but no definition.

It might also help people not mixing and confusing type and contract annotations, mostly by forcing them to write contract annotations everywhere inside record contracts, outside record type.

TODOs

• Fix the issue that right now, doing {foo = 5} | {foo : String} fails as expected, but let Foo = {foo : String} in {foo = 5} | Foo doesn't. The reason is that the latter isn't inside a type annotation, and is thus parsed as a record literal which is applied through merging, making the type annotation inoperative (which is the point of this PR). I think the solution is to make {foo : String} to become the contract associated to the corresponding record type all the time, not only inside type annotations. Additionally, we should forbid a type annotation to be attached to a field without a definition inside a normal record, because it's useless (that is, forbid {foo : String, bar | Number} or {foo : String, bar = 2} because the type annotation is useless and it might lead to surprising result; it can become a warning later on).