Experiment to factor out GC into its own project

[ekrich]

In general, I was thinking that GC and unwind could be factored out into there own project. Of course code that is intertwined is not great. The way the depends are done is a bit strange but I was only trying to get something to work.

This is not ready for prime time and we would have to think through several issues.

1. GC is using platform/unwind.h so it is duplicated - this I don't think we should do this and the offending code should be removed. How we could do OutOfMemoryException well is not determined but this isn't it.
2. The GC.scala code uses basic types. The only way I could see this working is to have a basic type library that is used by nativelib, gclib, and others. We might be able to think about what is runtime only or public - I know this is pretty mushy right now.
3. Runtime Arrays call the GC.scala directly so this dependency doesn't work. Not sure what could be done here.

Note: this has tons of changes as it is based on the other build PR. Some of the ability to reorganize here is based on the that PR for convenience. Probably doesn't need to be but ...

Note: Rebased on top of #3389

[WojciechMazur]

Thank your the POC, however, I would be against of moving the GC to other project, here's why:

1. nativelib is basically Scala Native Runtime with the GC as it's integral component. It would be impossible to run ScalaNative without GC and I don't think at any point we would be able to eliminate it completlly.
2. Moving the GC to seperate project does not fix or improve anything yet. One possibility would be to have a distinct project for each GC implementation. However, doing so is also tricky and not promissing. The NativeConfig is applied to far in the build to be able to efficently resolve GC dependencies (jars) based on provided config without integrating with each build tool. On the other hand if we'd move it to normal libraryDependenices of sbt or other build tool, then we cannot control what exactly would be present on class path, so we might end up with 2 GCs being compiled and failing to link due to duplicate symbols.
3. I've seen that you needed to move SafeZone to gclib. This change on it's own seems wrong, becouse this type has nothing to do with the GC, beside using it's API to specify memory ranges which shall be scanned. It shall always be simply a part of runtime library.

If at some point, we find a problem for which moving out GC would bring the improvement then your change would be a good place to start with. Once again thank you for your effort and experimenting with the code.

[ekrich]

See #3555 (comment)