Bug fixes for LLVM back-end

Address a number of problems with the LLVM backend discovered
in more thorough testing.

All tests were printing out errors like
 $CHPL_HOME/modules/standard/IO.chpl:759: warning: Could not find extern
def of S_IRWXU
I've disabled this warning for now (so we can have more sane testing),
but that's not the best long-term solution (see below).

These tests rely on C backend functionality and gained a skipif:
 compflags/shannon/cpplines/cppLines
 statements/diten/op_equals_using_C_primitive
 execflags/sungeun/about

These tests were failing because of a bug in how the LLVM backend
handled calling functions compiled by clang that pass structures
in registers or return structures in registers. I've fixed those bugs
by reworking that section of code.
 extern/bradc/structs/externFloat4calls
 extern/bradc/structs/externFloat4calls.someFields
I also added a new test to stress these capabilities:
 extern/ferguson/crazyRecord

This test was failing because the LLVM backend tried to pass a homogenous
tuple by value (instead of by pointer) to an extern function.
 users/ferguson/tuple_to_extern
Because Chapel passes them by pointer and C always will (e.g. int arr[10] as
an argument will pass a single pointer, and not 10 values, as function
arguments), I've modified codegenValue to keep star tuples/homogenous tuples
as pointers with isLVPtr set. (I investigating making them have isLVPtr=value
but that messed up other logic to do with copying them...). Since
codegenValue never really produces the value anymore, I needed to modify
codegenCopy to always use memcpy for star tuples. 

These tests used #defines when a static inline function would do. That's
a problem because the LLVM backend doesn't support complicated extern
#defines (see below remaining issues).
 studies/filerator/findfiles
 studies/filerator/walk
 studies/filerator/globberator
 studies/glob/test_glob
I changed the #defines to static inline functions.

Remaining Issues:
 link/sungeun/static_dynamic does not work with --llvm
 S_IRWXU and friends won't work unless we:
  - manually add a wrapper
  - support math directly when handling macros
  - or, add some kind of macro-to-function feature.

Testing:
 All tests pass with -compopts --llvm except for
[Error matching program output for io/fsouza/chown/permission_error]
[Error matching compiler output for link/sungeun/static_dynamic (compopts: 1)]
[Error matching compiler output for link/sungeun/static_dynamic (compopts: 2)]
[Error matching compiler output for link/sungeun/static_dynamic (compopts: 3)]
[Error matching program output for types/range/hilde/maximalRange (compopts: 1

I'm leaving static_dynamic as future work and the other two fail for me
in C backend testing.

I'll do GASNET+LLVM and --llvm-wide-opt testing next.


It's not a big deal. Division isn't that slow. It's true that the entire strategy here with doGetTypeFieldNext is probably expensive computationally, but the things that it should apply to fit into a few registers and so have limited complexity. I struggled to get this to work correctly (as far as I know it's correct) and will not rewrite it to improve performance without knowing 1) that it actually works correctly and 2) that the current strategy is a performance problem.