[BuildTools] An upcoming glpk glitch

[Lou Hafer]

Folks,

	While working on OsiGlpk, I noticed that glpk has changed the way it
defines symbols.  Glpk defines aliases in its include files.  As of 4.13, it
used

#define lpx_simplex           glp_lpx_simplex

As of 4.15, it uses

#define lpx_simplex           _glp_lpx_simplex

Note the leading underscore. Also, the organisation of the .h files has changed.
I haven't pulled 4.14 to pinpoint the change.

	The immediate challenge on the buildtools side is that we'll probably
need to cope with both versions for a while.  The immediate workaround (for
those who can't rebuild configure files locally) is the existing
--disable-*-libcheck hook.  Longer term, there are a couple of options:

  1) Extend COIN_HAS_USER_LIBRARY so that it accepts a list of symbols, and
     considers the check successful if any one of them succeeds.

  2) Extend COIN_HAS_USER_LIBRARY so that it #includes the .h file supplied as
     the third parameter when it makes the link check for the fourth parameter.

  3) Some combination of the above.
  
  4) Do something in individual configure.ac files (not preferable, in my view).

Looking at COIN_HAS_USER_LIBRARY, we might also want to begin the conversion
from AC_TRY_LINK (now deprecated) to AC_LINK_IFELSE.

	Either of 1) or 2) will solve the problem for glpk.  Option 2) might
protect us into the future, but actually using an include file in the link test
has its own hazards.  Upgrading to AC_LINK_IFELSE offers the opportunity for
some language independence, by way of using AC_LANG_PROGRAM.

	I'll add something to the BuildTools tickets and Known Issues pages.
But I wanted to get this out to the list to see if people have opinions about
which direction to pursue, or cautions from previous experience.

							Lou