[lmi] Distinguish $exec_prefix from $prefix ?

[Greg Chicares]

Vadim--Here's the full commit message cd1b383b (odd/multiarch branch).
I wonder if you have any comments.

Distinguish $exec_prefix from $prefix

In theory at least, $exec_prefix is separate from $prefix:

https://www.gnu.org/prep/standards/html_node/Directory-Variables.html
| Generally, $(exec_prefix) is used for directories that contain
| machine-specific files (such as executables and subroutine libraries),
| while $(prefix) is used directly for other directories.

https://www.gnu.org/software/autoconf/manual/autoconf.html
| exec_prefix
| The installation prefix for architecture-dependent files.

and $exec_prefix needn't be identical to $prefix or even a subdirectory
of $prefix--in theory at least.

Thus, instead of building autotoolized libraries this way:
  --prefix=/opt/lmi/"$host_type"/local
  --exec-prefix="$prefix"
it would seem better to build them this way [option X]:
  --prefix=/opt/lmi/local
  --exec-prefix="$prefix"/"$host_type"
or even this way [option Y]:
  --prefix=/opt/lmi/local
  --exec-prefix=/opt/lmi/"$host_type"/local

Attempting to use option Y failed in ways that seemed difficult to fix
(wxWidgets built successfully with either X or Y, but liblzma and
libxml2 didn't; perhaps their maintainers have blithely assumed that
$exec_prefix is a subdirectory of $prefix), so this commit implements
option X. And it's almost successful: lmi builds and works correctly
except that lzma support for product files fails the test here:
  https://lists.nongnu.org/archive/html/lmi/2017-08/msg00061.html
That failure is not unanticipated, because libxml2 configuration says
  "checking for LZMA...no"
for option X, both with and without this change:
-  --with-lzma=$(prefix) \
+  --with-lzma=$(exec_prefix) \
The difference is that without that change, compilation halts because
lzma headers cannot be found, whereas with that change, the library
appears to build despite the "LZMA...no" warning (yet fails to support
liblzma).

Therefore, although this revision is committed because it's interesting,
apparently it must be reverted because the autotoolization of libraries
in widespread use is incompatible with the autotools vision, and the
only reliable method is '--exec-prefix="$prefix"', which installs
architecture-independent headers to an architecture-dependent directory.

It is also noteworthy that 'install_msw.sh' had to change, replacing
'/opt/lmi/"$LMI_HOST"/local/bin' with '/opt/lmi/local/"$LMI_HOST"/bin'.
This suggests that it's a defect to compose such paths in multiple
places (and there are other likely defects in the same file, in cygwin-
specific code). Perhaps this means that all the local variables in
'set_arch.sh' should be exported.