Revised error design

[jclark]

This issue covers a new error design that deals with issues #459, #393, #501. It takes advantage of the distinct type feature from #413.

• errors are categorized using type-ids, which are part of the distinct type feature rather than the error reason string
• the error reason string is removed
• the error type descriptor has a single type parameter, which specifies the detail record
• message and cause move from the detail record into the error itself
  • the type is string and error? respectively
  • the message is required
  • the cause defaults to () if not specified
  • they are specified by positional arguments to the error constructor
  • lang.error provides message and cause functions to access them
• the required type of detail record is map<anydata|readonly> (with no predefined fields)
• the positional parameters of error constructors specify the message and cause
• if the error constructor uses a type that does not specify a detail record type with individual fields, then named arguments can be used to specify arbitrary fields
• if the error constructor uses a type that does specify a detail record type with individual fields, then the named arguments can only be used to specify those fields; other fields must be specified with ... and a mapping constructor (not sure if this functionality is really necessary)

Intersection types #508 allow a type descriptor to describe both the type-ids and the detail record.

[jclark]

Nominal types design also includes the following.

An error type error<R> means that the detail record must belong to the type

    readonly & record {| *R; (anydata|readonly)...; |}

In a match-statement, a error-match-pattern with a user-defined error type should match only if the shape of the value belongs to type.

[jclark]

We also need to fix toString for error as described in #459 (comment)

[jclark]

Still to do:

• error<T> means detail record belongs to readonly & T
• explain when type descriptor for subtype of error can be used in functional constructor: must be definite and can be intersection
• toString on error should include primary type ids
• restriction on when individual field names can be used in error constructor
• rest argument in error constructor
• avoid poor interactions between intersection and exclusive record types

Last two are about how openness should work for the detail record; not yet 100% confident we have this right.

[jclark]

I have moved the remaining parts of this into #550.