Make supplier a library type instead of a built-in type

[MeAmAnUsername]

Short description
Suppliers can be regular library types, their only special traits are that they are the return value of a task supplier call (task.supplier(args)) and that they generate special Java code.

Todo list

• Add suppliers to PIE standard library and publish the library
• Make the standard library definition of mb.pie.api.Supplier the return value of task suppliers
• Modify compiler to generate correct code for Supplier#get

Reason
As a built-in type every part of the language definition needs to be aware of this type. Task suppliers do not require a special built-in supplier type (requires #157). This would remove the supplier type and function from the syntax and static semantics, and possibly a whole bunch of SPT tests for suppliers (we could keep them, although that would require access to the standard library from within SPT tests).
Making the language definition smaller also decreases the amount of special cases users need to remember when learning the language.

Implementation
Definition in the pie standard library:

data Supplier[T] = foreign java mb.pie.api.Supplier {
  func get() -> T
}
func supplier[T](value: T) -> Supplier[T] = foreign java constructor mb.pie.api.Supplier

The compiler can introduce a check in p2j-ast-call: QCall that checks the implementation of the type, and if it is mb.pie.api.Supplier, generate special code:

p2j-ast-call: QCall(exp, name, args) -> result
  where
    "get" := <remove-annotations> name
  ; ty := <get-type> exp
  ; decl := <get-decl> ty
  ;  ForeignJavaDataImpl(impl) := <get-implementation> decl
  ; "mb.pie.api.Supplier" := <remove-annotations> impl
  with
    // generate code for supplier.get call

p2j-ast-call: QCall(exp, name, args) -> result
  with
    // normal code generation for QCalls

    

Related issues

• See Create libraries #7 for other library types.
• See Refer to library types from language #157 for how to integrate the special cases into the language.
• This issue depends on DSL generics #24.
• Result type #84 has another type commonly used with PIE, but Result is fully supported without the need for special cases in the compiler or language.