[mmtk-julia] Allow building Julia with variations of the binding

[udesou]

This PR enables building the mmtk-julia binding with different configurations other than non-moving Immix. While it was already possible to do so when building from source, this should enable using the binaries generated via the latest version from BinaryBuilder (JuliaPackaging/Yggdrasil#10357).
I have also decoupled MMTk from the code, such that it should be an option for a third-party heap. This should be set using WITH_THIRD_PARTY_GC=mmtk (in Make.user or as an environment variable).

The different configurations of MMTk can be achieved by setting the variables below (set in Make.user, for example):

Variable
MMTK_PLAN	Immix	StickyImmix
MMTK_MOVING	0	1
MMTK_BUILD	release	debug

Note that the actual code to support building with moving and sticky immix will be added in future PRs.
I've also added some preliminary documentation in doc/gc.md about building Julia with MMTk, including a link to the binding and an small FAQ on what to do if you break the build of Julia+MMTk.

[d-netto]

I have some reservations about this paragraph. In particular:

• We could make the explanation about what the MMTk acronym stands for a lot more explicit. You implicitly explain it in the sentence MMTk is a memory management toolkit, but I think we should probably put this in a parentheses right after the first time the acronym is mentioned. I.e. MMTk (Memory Management Toolkit).

• The sentences The flexibility comes from the fact that it is possible to switch implementations fairly easily. MMTk supports state-of-the-art high-performance implementations that are continuously added and maintained in the core part of the framework. MMTk is under active development and has been used by other programming languages such as [Java](https://github.com/mmtk/mmtk-openjdk) and [Ruby](https://github.com/ruby/mmtk).

Don't seem like a good fit for a developer documentation.

As a core developer, I'd be a lot more interested in knowing that MMTk will allow me to experiment with a range of algorithms ranging from a simple serial mark-sweep GC to a sophisticated moving and concurrent GC (e.g. LXR), and having a brief explanation about why the design/architecture of MMTk allows me to that easily -- using a bit of technical terminology would be fine, since it's a developer documentation.

The sentences describing that (implementations) are continuously added and maintained in the core part of the framework and MMTk is under active development seem unnecessary: these seem like minimum expectations for any high-quality software project.

Citing other languages that adopted MMTk doesn't seem necessary in this documentation either.

[d-netto]

We're only instructing users to set WITH_THIRD_PARTY_GC and MMTK_PLAN in the Make.user, but then mention that there are other environment variables available (MMTK_MOVING, MMTK_BUILD).

This is a bit confusing, and it's possibly coming from the fact that we don't support moving yet.

I think we should mention that these variables can also be set, but at the time we're writing this, they will be no-ops, throw an error or something else because we don't support moving yet.

[d-netto]

Having this file seems a bit too much at the moment.

We don't plan to support any other third-party GC in the foreseeable future, so I'd just directly inline this logic:

#ifdef WITH_THIRD_PARTY_HEAP
#if WITH_THIRD_PARTY_HEAP == 1
#include "gc-tls-mmtk.h"
#endif

into julia_threads.h.