Control.Elab.ovlddisable: Disable integer overloading

[Skyb0rg007]

This change adds the controls flag ovlddisable that prevents the toplevel functions ~ + - * div mod < <= > >= abs as well as integer and word literals from participating in overload resolution.
These functions will take on their default types, which is int for the functions and integer literals, and word for word literals.

Description

This adds the flag to the Elaborator controls file.
It also adds a dummy "Overload.new" function that resolves variables and literals immediately, instead of waiting.

Motivation and Context

When teaching Standard ML, one thing to stress is how everything is properly typed.
Showing this off in SML/NJ leaves one bewildered:

- [1, true];
stdIn:1.2-1.11 Error: operator and operand do not agree [overload - bad instantiation]
  operator domain: 'Z[INT] * 'Z[INT] list
  operand:         'Z[INT] * bool list
  in expression:
    1 :: true :: nil

This issue has even gotten worse from older releases, since in 110.79.0 the overloaded types were displayed as [int ty] instead of the scary 'Z[INT].

With this flag, one gets a much nicer error message:

- Control.Elab.ovlddisable := true;
- [1, true];
stdIn:4.1-4.10 Error: operator and operand do not agree [tycon mismatch]
  operator domain: int * int list
  operand:         int * bool list
  in expression:
    1 :: true :: nil

This commit is not aimed at the development version of SML/NJ for good reason: this is a hack.
Really the compiler should either instantiate overloaded types before showing them to users such as MLton does.
But since SML/NJ is currently being used by students that have no use for language features such as overloading, this should be able to be hidden from view.

How Has This Been Tested?

This has not been extensively tested.

[JohnReppy]

Can you add documentation explaining what the "new_stub" function is doing in detail (also, it should be called "newStub"). The name "new_real" is a poor choice, since "real" is a type name.

[JohnReppy]

It is unclear what happens when one has a non-default-type literal. Will something like

fun fact (ba, i, b) = Word8Array.update(ba, i, b+0w1);

typecheck?

[Skyb0rg007]

This PR is somewhat of a mess; in it's current state the flag is only potentially useful for debugging purposes.
Enabling the flag prevents all overload instantiation, including your example: you would need to write:

fun fact (ba, i, b) = Word8Array.update (ba, i, Word8.+ (b, Word8.fromInt 1));