Flesh out iiglue reader to read and store inferred array info.

We are now loading JSON-formatted iiglue analysis results and associating those results with the appropriate LLVM objects representing program components.  However, the reader is customized for just the iiglue information we actually need.  Right now, we only care which formal function arguments are arrays.  So we extract that and provide a convenient API for querying it from other passes.  Any other iiglue analysis output is quietly ignored.
Configure various static style checkers run by Emacs's flycheck mode.
Tell git to ignore Emacs backup files.
Add printing support that dumps loaded iiglue data.

This should help for scripting tests.  Toward that end, I go to some trouble to make sure the output is ordered consistently.  That does depend on Clang giving consistent names to Argument instances, though.  If that turns out to be too brittle, then we could instead use each Argument's index number instead of its name.  That will definitely be consistent everywhere, though it's less human-readable.
Rename a command-line flag.

Instead of mixing similar terms "input" and "read", just pick one and stick with it consistently.
Add a basic automated IIGlueReader test.

I expect this infrastructure will grow more sophisticaed over time, such as when we have more than just one test.  :-)  But for now it's good to have something in place to build upon.
A few more test-related changes that I forgot to commit previously.
Add some helpful custom scons tools from my personal library.

One of these is good for creating LLVM bitcode from either C or C++ code.  The other knows how to compare actual and expected file contents, and touch a ".passed" stamp file if the files match.

Use these two tools where appropriate in our testing logic.  They don't do much for us now, since we have only one test.  But they will make things more convenient as the test suite grows.
Rebuilt JSON output from iiglue.

Apparently iiglue does not add a trailing newline to its output.  We ended up with one here because I hand-edited this file at some point.  Removing it (in this commit) brings us back to what iiglue really does produce as its output.
Add an iiglue reader test for variadic functions.

To my surprise, this actually worked right from the start, requiring no IIGlueReader changes.  Cool!  Having this test should help ensure it keeps working.
Enable RTTI when building our plugins.

LLVM prefers to disable RTTI.  They have their own approach to dynamic typing that they like better.  But we're already making heavy use of Boost, and some Boost features do need RTTI.  Hopefully these two big libraries can coexist peacefully.

Interestingly, this worked fine without forcing RTTI on when building on my personal Fedora 20 box.  But on a departmental RHEL 6 box with locally-built LLVM 3.3 and Boost 1.55.0, we run into problems without this tweak.
Prefer a slightly more modern GCC, if available.
Make a single-argument construction look more like initialization.

I generally prefer "=" initialization when there's only one argument.  For example:

````
int x = 5;
point p(5, 6);
````
Remove an unused construction variable.
Factor out common logic of two similar flag tweaks
On CS machines, look for our own local installation of LLVM.

This local installation was built using the CSL-installed gcc-4.9.0.  All of its executables and shared libraries have the proper RPATH settings to find the correct gcc-4.9.0 C++ runtime library.  That, in turn, means we can also use gcc-4.9.0 for building our own LLVM passes here.
Merge pull request #1 from AlisaMaas/iiglue-reader

iiglue reader pass plus basic testing infrastructure
Minor build tweak: hoist a loop-invariant assignment out of a loop.
Link our plugin with the main LLVM shared library.

Also link with any other libraries that "llvm-config" claims we will
need.

This will make no difference in practice, but I consider it good style
for every shared library to link with the libraries that provide
symbols it uses.  Otherwise, you're depending on someone else to pick
those up for you transitively, which can be fragile in general.
Help Emacs flycheck find the local LLVM installation on CS machines.