Implemented AMBER_PATH for import lookup

[Thesola10]

This fixes #668 and opens up possibilities for simpler package managers, as they could export a set of standard paths.

Now, if AMBER_PATH is set to /usr/lib/amber:$HOME/.local/lib/amber for instance, in addition to the current directory, import directives will look in those directories as well.

This is a draft/proof-of-concept and there's a couple things to do:

•  Exclude paths that start with . or .. from environment lookup
• Define a default set of AMBER_PATH paths
• Ideally move the stdlib out into one of these paths (how do other cargo projects distribute installable resources???)

[b1ek]

i dont know if this is the right way forward. wouldn't it cause a lot of confusion and inconsistency between different package managers? since there is no rigidly defined place where should they place their packages

[Thesola10]

i dont know if this is the right way forward. wouldn't it cause a lot of confusion and inconsistency between different package managers? since there is no rigidly defined place where should they place their packages

That is how every compiler does it under the hood. There are default values (which I intend to add for Amber as well as soon as I can make sure we can ship stdlib in one of them) but leaving this path system open allows for integrating with other buildsystems like Meson, Autoconf or Nix, where dependencies may not be in standard paths for technical reasons.

In the future adding a default package manager to Amber isn't incompatible with this option, just wish to keep modularity in mind -- amber would be a git-like modular CLI which could call amberc, a pure and simple compiler.

Another reason to allow flexible paths is virtual environments. The only way to prevent dependency collision is to let users specify where dependencies are on a per-project basis.

Just as Python developers rarely think about PYTHONPATH, ideally you won't need to know about AMBER_PATH. Your build tool just sets it for you.