Squash speculative gmp and re2 builds when they have previously failed.

Before this change, a user would speculatively try to build gmp and re2 over
and over again when they failed. This updates the gmp, re2, and third-party
Makefiles to only attempt the speculative build once per configuration
regardless of whether the speculative build succeeds or fails. The user is
warned that the speculative build is squashed when it has previously failed.

The third-party makefile checks for the presence of the config-specific build
subdir (e.g. build/darwin-clang-native) and only builds when that directory
does not exist. The gmp and re2 makefiles create that directory first, so it
will exist even if the respective build fails.

When the config-specific build subdir does exist, the third-party makefile then
checks for an expected header file in the install subdir (similar to what
util/chplenv/* does to auto-detect gmp and re2). If the header does not exist,
but the build subdir does, the user is warned that the respective speculative
build is squashed due to a previous failure.

Along the way, gmp and re2 makefiles were cleaned up a bit (mostly for my
understanding).

I'm a little concerned about losing the foo-config and foo-build steps for the following reasons:

1) consistency with other third-party Makefiles (minor)

2) as a developer I often manually invoke one or the other to debug part of the build process and find it easier to use target names like this than to try and come up with the file/directory that will trigger the same behavior (particularly when it's based on things like CHPL_TARGET_COMPILER and such...).  I do like that the common case doesn't rely on as many phony rules now, though.  Maybe a compromise solution would be to preserve gmp-build/config steps and have them simply name the target as a dependence?  (though that loses the FORCE semantics that they had previously for better or worse).

3) I'm trying to remember why but I've also always been nervous about whether dependences like these are sufficient for re-building autoconf-based projects if/when files within them change (say someone is editing a .c or .h file) which is probably why I used the heavy-handed FORCE to always re-build when someone asks to do so.  Maybe I need to get over that, not sure.