Switch ABI references to env/environment

[lamb-j]

Summary

To be consistent with Triple.h, we update references to the
optional fourth triple field from ABI to env or enviornment

[rengolin]

IIRC, "abi" used to be what Arm called, but "env" is equally good. And it it's consistent with Triple.h, even better. LGTM, thanks!

clang/docs/CrossCompilation.rst

 -------------
 
 The basic option is to define the target architecture. For that, use
 ``-target <triple>``. If you don't specify the target, CPU names won't
 match (since Clang assumes the host triple), and the compilation will
 go ahead, creating code for the host platform, which will break later
 on when assembling or linking.
 
-The triple has the general format ``<arch><sub>-<vendor>-<sys>-<abi>``, where:
+The triple has the general format ``<arch><sub>-<vendor>-<sys>-<env>``, where:
  * ``arch`` = ``x86_64``, ``i386``, ``arm``, ``thumb``, ``mips``, etc.
  * ``sub`` = for ex. on ARM: ``v5``, ``v6m``, ``v7a``, ``v7m``, etc.
  * ``vendor`` = ``pc``, ``apple``, ``nvidia``, ``ibm``, etc.
  * ``sys`` = ``none``, ``linux``, ``win32``, ``darwin``, ``cuda``, etc.
- * ``abi`` = ``eabi``, ``gnu``, ``android``, ``macho``, ``elf``, etc.
+ * ``env`` = ``eabi``, ``gnu``, ``android``, ``macho``, ``elf``, etc.
 
 The sub-architecture options are available for their own architectures,
 of course, so "x86v7a" doesn't make sense. The vendor needs to be
 specified only if there's a relevant change, for instance between PC
 and Apple. Most of the time it can be omitted (and Unknown)
 will be assumed, which sets the defaults for the specified architecture.
 The system name is generally the OS (linux, darwin), but could be special
 like the bare-metal "none".
 
 When a parameter is not important, it can be omitted, or you can
 choose ``unknown`` and the defaults will be used. If you choose a parameter
 that Clang doesn't know, like ``blerg``, it'll ignore and assume
 ``unknown``, which is not always desired, so be careful.
 
-Finally, the ABI option is something that will pick default CPU/FPU,
-define the specific behaviour of your code (PCS, extensions),
+Finally, the env (enviornment) option is something that will pick default
+CPU/FPU, define the specific behaviour of your code (PCS, extensions),
 and also choose the correct library calls, etc.
 
 CPU, FPU, ABI
 -------------
 
 Once your target is specified, it's time to pick the hardware you'll
 be compiling to. For every architecture, a default set of CPU/FPU/ABI
 will be chosen, so you'll almost always have to change it via flags.

 copies of your libraries and (possibly) headers.
 
 Some Linux distributions have support for Multilib, which handle that
 for you in an easier way, but if you're not careful and, for instance,
 forget to specify ``-ccc-gcc-name armv7l-linux-gnueabihf-gcc`` (which
 uses hard-float), Clang will pick the ``armv7l-linux-gnueabi-ld``
 (which uses soft-float) and linker errors will happen.
 
-The same is true if you're compiling for different ABIs, like ``gnueabi``
-and ``androideabi``, and might even link and run, but produce run-time
-errors, which are much harder to track down and fix.
+The same is true if you're compiling for different environments, like
+``gnueabi`` and ``androideabi``, and might even link and run, but produce
+run-time errors, which are much harder to track down and fix.