RFR: JDK-8198724 Refactor FLAGS handling in configure

[Magnus Ihse Bursie]

The current way we're handling FLAGS (CFLAGS/CXXFLAGS, LDFLAGS, etc) is 
laden with technical debt. It's a sorry mess, hard to do anything 
constructive about.

This is the first step towards a better solution. The main goal is to 
have a set of more specific flags, more like how the SYSROOT flags work 
today, that can be individually included, instead of a huge CFLAGS_JDKLIB.

To make such a change manageable, this first step will (almost) only 
refactor the autoconf code, but will output the same flags in the spec.gmk.

To minimize special cases, I have accepted the following differences:
* On linux/gcc, we will get a -m<bits>, e.g. -m64 always (as on 
aix/solaris).
* On macosx/clang, we will get a -m<bits>, e.g. -m64 always (as on 
aix/solaris).
* On macosx/clang, we will now "hardcode" the max/min version number 
without dots.
* On macosx/clang, the JVM_CFLAGS for the build toolchain will now also 
get an -fPIC (this was mysteriously missing before).
* On windows/microsoft, the build toolchain will now get -nologo added 
as well, and also -homeparams for debug builds.
* On solaris/solstudio, the JDKEXE flags will now include -errfmt, and 
CFLAGS_JDKEXE will include -errtags=yes. The duplication of -errtags=yes 
in CXXFLAGS_JDKLIB is removed.
* On solaris/solstudio, we now always use -KPIC as pic flag. 
(Previously, we used -xcode=pic32 on sparc, but this is equivalent to 
-KPIC, so there's no reason for a special case.)
* On solaris/solstudio, we now use e.g. "-Wc,-Qrm-s" instead of 
"-Qoption cg -Qrm-s" for C++ as well as for C code. The two formats are 
equivalent (for passing options to a certain compilation phase), and 
there was no reason to use different ones for C and C++.

And for clarity, I have also renamed some exported flags to clearly show 
that they are consumed by LIBJSIG and ADLC. I have also renamed "/STACK" 
on the Microsoft linker to "-stack", to match how we write options 
elsewhere.

I believe none of these should have any real effect, but if anything, 
they could probably be considered bug fixes.

I have considered whitespace and ordering differences as irrelevant.

I have manually verified that the generated spec.gmk and 
buildjdk-spec.gmk matches this (no changes apart from the one listed 
above) for linux/x64/gcc, solaris/sparcv9/solstudio, 
windows/x64/microsoft and macosx/x64/clang, for release and fastdebug.

I am also currently running a test job using the COMPARE_BUILD 
functionality on our internal build system.

I would appreciate if comments are more in the form of "think of this 
for subsequent updates to the flag handling" rather than requests to 
change this patch, at least for requests that are just not small fixes. 
(I've been juggling this for a while, trying to get it right...)

Bug: https://bugs.openjdk.java.net/browse/JDK-8198724
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8198724-refactor-flags-step-1/webrev.01

/Magnus