Improve current design of intrinsic bindings

Even though the current design of foreign bindings will hopefully be replaced by proper C FFI with the ability to specify calling conventions etcetera, we should improve the current situation for now.

Right now, foreign bindings are not namespaced. They should respect the module system. For example today, a foreign binding alpha in module crate.some.where.here is referenced by the string "alpha" on the Rust side. But ideally, it should only be referenceable by the string "crate.some.where.here.alpha" or without the leading crate. until we have a crate system. If we have a crate system in place, it should maybe be core:some.where.here or core.some.where.here or something else depending on how the final design of the crate system looks like.

Then, update the bindings for core.

For the purpose of developing this language implementation in stages, it should also be possible to explicitly add this "foreign key" to @foreign. E.g. @(foreign core.some.where.here.alpha) or @(foreign "core:some.where.here.alpha"). This should only be temporary. The motivation is the gained ability to develop the byte code generator without the need to reference and therefore also support the whole standard library core. E.g. we might like to generate code for very simple code snippet using very few features but requiring let's say the type Int32. It can then easily be included like this:

;; module core ;; <- not necessary!

@(foreign core.int32.Int32)
data Int32: Type

;; ... rest of the code ...

Without namespaces, we cannot add identically named (up to the local module) bindings from different modules. That's what we'd like to do in core: Function add in modules Nat, Nat32, ..., Int, ....

fmease / lushui

Improve current design of intrinsic bindings #39