Fix two bugs for 64-bit slang.

The first is to handle structs in invoke parameter lists by assuming struct and
not struct*. The second is to not cache LLVM types for RS object types because
it breaks on 64-bit compilation.

Cherry-pick of d56a92fc2b1d417ce53d9550548fe1661fa37d40

Change-Id: I26d7dd7395ef0146eb84d43cbec5cf8d49d09697
Merge "Fix two bugs for 64-bit slang."
Replace the NULL macro with nullptr literal.

Change-Id: I33609969cd0d7aa55eaa83fb2c65f5faa6d55fa0
Merge "Replace the NULL macro with nullptr literal."
Fix tests for 64-bit.

Bug: 16031597

This change also copies over an existing test (P_export_types) that would
break under the new 64-bit compilation mode (since some types no longer exist).

Change-Id: Ia719e69cd9df4d0bdc814b16223d791055f2d616
(cherry picked from commit 55c081c6754f128049f56ed2342a07b601849ce9)
Suppress warnings on our second compilation (for 64-bit).

Bug: 16031597
Bug: 17052573

Without this patch the 64-bit compilation path will print duplicate warning
diagnostics, since we call the frontend twice (for 32-bit, and then 64-bit).
The simplest fix is to not print warnings for the second compilation. A bug
(17052573) has been filed to track fixing this a better way (actually printing
out all warning diagnostics, but removing duplicates explicitly).

Change-Id: I78ac0ebd2b132713ec0c86c2cf234da2b620eecf
(cherry picked from commit 2d504fd03c66be56ac3b4bb62c78cc72c75dd8b6)
Merge "Fix tests for 64-bit."
Merge "Suppress warnings on our second compilation (for 64-bit)."
Fix dangling reference to a local std::string.

Bug: 16031597

llvm::StringRefs are just lightweight wrappers around strings, and don't
retain/own any of the storage for the actual underlying string. This causes
lifetime issues if any local std::string objects that are then wrapped by
llvm::StringRef ever escape. When the local object goes out of scope, we are
left with a dangling reference.

Valgrind helped us to catch this happening for constant array exports, which
only ever use a statically named "<ConstantArray>" reference, so we can
simply replace it with static C string (wrapped by llvm::StringRef).

Change-Id: I0a9fae2687bc9f53d091d56cf15f99bb75ca46e4
(cherry picked from commit 340b5550cf63b6beae3b12c2e91377bce7704c34)
Merge "Fix dangling reference to a local std::string."