Clean up docs references to './configure' in preparation for deprecating in-source builds

[jroelofs]

Summary

There's a couple of remaining ones that I didn't touch:

./docs/GoldPlugin.rst:163:     % ./configure && make && make check
./docs/LibFuzzer.rst:88:  (cd pcre; ./autogen.sh; CC="clang -fsanitize=address $COV_FLAGS" ./configure --prefix=`pwd`/../inst && make -j && make install)
./llvm.spec.in:28:./configure \

The first is for building Gold, which I'm not familiar enough with to make the change (AFAICT it's referring to a different configure file anyway).
The second I believe is referring to a different configure file. Not sure though... @kcc?
I don't know what the third file is.

[kcc]

The second I believe is referring to a different configure file. Not sure though... @kcc?

Yes, this ./configure is from a totally different package and is here just as an example.

[echristo]

Inline question, otherwise feel free to have at with the changes for this.

-eric

docs/FAQ.rst

105

Can we use a $LLVM_SRC_DIR here as well?

[jroelofs]

r236144

autoconf/configure.ac

 #include <unwind.h>
 #endif
 ]])],
 [
   AC_MSG_RESULT([yes])
 ],
 [
   AC_MSG_RESULT([no])
-  AC_MSG_ERROR([Selected compiler could not find or parse C++ standard library headers.  Rerun with CC=c-compiler CXX=c++-compiler ./configure ...])
+  AC_MSG_ERROR([Selected compiler could not find or parse C++ standard library headers.  Rerun with CC=c-compiler CXX=c++-compiler SRC_ROOT/configure ...])
 ])
   AC_LANG_POP([C++])
 fi
 
 dnl Set up variables that track whether the host compiler is GCC or Clang where
 dnl we can effectively sanity check them. We don't try to sanity check all the
 dnl other possible compilers.
 AC_MSG_CHECKING([whether GCC or Clang is our host compiler])

configure

 
 else
   echo "$as_me: failed program was:" >&5
 sed 's/^/| /' conftest.$ac_ext >&5
 
 
   { echo "$as_me:$LINENO: result: no" >&5
 echo "${ECHO_T}no" >&6; }
-  { { echo "$as_me:$LINENO: error: Selected compiler could not find or parse C++ standard library headers.  Rerun with CC=c-compiler CXX=c++-compiler ./configure ..." >&5
-echo "$as_me: error: Selected compiler could not find or parse C++ standard library headers.  Rerun with CC=c-compiler CXX=c++-compiler ./configure ..." >&2;}
+  { { echo "$as_me:$LINENO: error: Selected compiler could not find or parse C++ standard library headers.  Rerun with CC=c-compiler CXX=c++-compiler SRC_ROOT/configure ..." >&5
+echo "$as_me: error: Selected compiler could not find or parse C++ standard library headers.  Rerun with CC=c-compiler CXX=c++-compiler SRC_ROOT/configure ..." >&2;}
    { (exit 1); exit 1; }; }
 
 fi
 
 rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
   ac_ext=c
 ac_cpp='$CPP $CPPFLAGS'
 ac_compile='$CC -c $CFLAGS $CPPFLAGS conftest.$ac_ext >&5'

docs/BuildingLLVMWithAutotools.rst

``gmake dist-clean``
 
   Removes everything that ``gmake clean`` does, but also removes files generated
   by ``configure``.  It attempts to return the source tree to the original state
   in which it was shipped.
 
 ``gmake install``
 
   Installs LLVM header files, libraries, tools, and documentation in a hierarchy
-  under ``$PREFIX``, specified with ``./configure --prefix=[dir]``, which
+  under ``$PREFIX``, specified with ``SRC_ROOT/configure --prefix=[dir]``, which
   defaults to ``/usr/local``.
 
 ``gmake -C runtime install-bytecode``
 
   Assuming you built LLVM into $OBJDIR, when this command is run, it will
   install bitcode libraries into the GCC front end's bitcode library directory.
   If you need to update your bitcode libraries, this is the target to use once
   you've built them.

docs/FAQ.rst

#. Adjust your ``PATH`` environment variable so that the correct program
    appears first in the ``PATH``.  This may work, but may not be convenient
    when you want them *first* in your path for other work.
 
 #. Run ``configure`` with an alternative ``PATH`` that is correct. In a
    Bourne compatible shell, the syntax would be:
 
 .. code-block:: console
 
-   % PATH=[the path without the bad program] ./configure ...
+   % PATH=[the path without the bad program] SRC_ROOT/configure ...
 
 This is still somewhat inconvenient, but it allows ``configure`` to do its
 work without having to adjust your ``PATH`` permanently.
 
 
 When creating a dynamic library, I get a strange GLIBC error.
 -------------------------------------------------------------
 Under some operating systems (i.e. Linux), libtool does not work correctly if

docs/HowToBuildOnARM.rst

 
 #. The most popular Linaro/Ubuntu OS's for ARM boards, e.g., the
    Pandaboard, have become hard-float platforms. The following set
    of configuration options appears to be a good choice for this
    platform:
 
    .. code-block:: bash
 
-     ./configure --build=armv7l-unknown-linux-gnueabihf \
+     ../$LLVM_SRC_DIR/configure --build=armv7l-unknown-linux-gnueabihf \
      --host=armv7l-unknown-linux-gnueabihf \
      --target=armv7l-unknown-linux-gnueabihf --with-cpu=cortex-a9 \
      --with-float=hard --with-abi=aapcs-vfp --with-fpu=neon \
      --enable-targets=arm --enable-optimized --enable-assertions
 
 #. ARM development boards can be unstable and you may experience that cores
    are disappearing, caches being flushed on every big.LITTLE switch, and
    other similar issues.  To help ease the effect of this, set the Linux