Add import statement support for dynamic extensions

[jow-]

Major changes:

lib: internally expose new uc_require_library() helper

Break out the core logic of the uc_require() stl function into a new uc_require_library() helper function and make it available for usage outside of lib.c. Also add a new boolean parameter to the helper function which allows restricting runtime require operations of modules to dynamic libraries only.

vm: introduce new I_DYNLOAD opcode

The I_DYNLOAD opcode is basically a bytecode level instruction for uc_require() with semantics similar to I_IMPORT. It allows loading a dynamic extension library at runtime and treating values from the resulting module context object like exports from a compile time source module.

For example the statement import { readfile, writefile } from "fs" would import the readfile() and writefile() functions of fs.so as readonly live bindings into the current file scope.

compiler: add import statement support for dynamic extensions

Utilize the new I_DYNLINK vm opcode to support import statements referring to dynamic extension modules.

During compilation, the compiler will try to infer the type of the imported module from the resolved file path; if it ends with .so, the module is assumed to by a dynamic extension and loading/binding of the module is deferred to runtime using I_DYNLINK opcodes.

Additionally, the -c cli option gained support for a new compiler flag dynlink=... which allows forcing a particular module name expression to be treated as dynamic extension. This is useful to e.g. force resolving import { x } from "foo" to a dynamic extension foo.so loaded at runtime even if a plain foo.uc exists in the search path during compilation or if no such module is available at build time.