Parser/Printer: unify uncurried functions of arity 0, and of arity 1 taking unit.

[cristianoc]

• Don't emit arity 0 for uncurried functions and types
• Get around the front-end's special treatment of application with () as zero-arity application, by using annotation @res.uapp for uncurried applications and have the compiler front-end treat it specially.
• Don't distinguish between types (. ) => int and (. unit) => int or in uncurried notation, between () => int and unit=>int.
• Don't distinguish between foo(.) and foo(. e), both unary applications
• Don't distinguish between (. ) => 3 and (. x) => x+1 both unary function definitions

This brings the uncurried subset of the language closer to the curried one.

[bobzhang]

I didn't dig into the details FYI the main use case for arity 0 is FFI where some Js functions need a arity 0 call back

[cristianoc]

I didn't dig into the details FYI the main use case for arity 0 is FFI where some Js functions need a arity 0 call back

I'll have some questions about implementation cleanup later, but for now looking at the user experience. Got into some issues when converting existing code to uncurried by default. The ideal conversion being: just do nothing. This did not work until now, but after removing arity 0 from the uncurried language that the user sees, it does work.