Build-system overhaul

64-bit build PC:s, whom are almost all multi architectural, don't place
glibc headers and libraries in a uniform way any longer to be able to
distinguish 32-bit from 64-bit versions. This creates a problem for us using
BUILDCHAIN wrapper method as this assumes there's only one path to the include and
library directories. When cross-compiling this is a non-issue as even if the
target is multi architectural, paths are handled differently.

Issue solved and mechanism, however: Names in a wrapped path that have
been defined will expand. For example:

/usr/include/x86_64-linux-gnu will expand to /usr/include/x86_64-1-gnu,
rendering include files not found. This is a tricky issue as the strings are
not really strings, which also explains why #include BUILDCHAIN(path) don't
take any surrounding " or <>. The preprocessor knows it's a string
implicitly due to it's # expansion and allows the construct, but we can't do
anything to manipulate or restrain it further.

Issue will be solved by identifying which macros are defined (easy to
determine) and undefine them (possibly temporarily if it turns out to
interfere with the tools or system).
BUILDCHAIN wrapper issue fixed
make mrproper

Light version 'make properhard'. Iterates trough the build structure like
the other well-behaved make-goals.
build environment: Test for empty/unset BOARD
Better build  cofigure error handling

Better error messages when dependency conflicts are detected.
Reformatting

Making the code at least somewhat bearable to read...
Finally builds for 64bit hosted linux-target

First time in ~10 years we've been in any hosted mode. A shit-load has
happened on the CPU front. uC and CPU:s have diverged and it's probably not
a very effective principle to store each context on top of each stack, at
least not without some thought (consider preemption which will recurse
the stack).

However, TinKer is first an foremost a deeply embedded kernel. Almost equally
important as embeddedness is transparency and portability. It's still
possible to port TinKer to a new architecture in a day, even by this ol guy.
That is made possible only by not using specialized HW supported features.

Even without fancy MMU, SMP and specialized context-stacks it still beats
linux silly on pure performance any-day for the executables it's made for
though. That's what this port (_x86_64) aims at proving.

Do we dare to fire it up? Nah, lets wait and gather courage.

Remaining issues:
More registers need context saving.
* r8-r15
* xmm8-xmm15

Might not be needed since xmm0-xmm4 wasn't saved last time it run on a
ancestor to x86, I'm sure it must had been a PII at least :-). Our threads
are not going to do streaming but should the context be required to use
these, dynamic detection of usage is a must as they are riotously large
(16x16 bytes).