ARM & AArch64: merge the semantic checking of NEON intrinsics

There are two kinds of automatically generated tests for NEON intrinsics, both
of which can be merged without adversely affecting users.

1. We check that a valid kind of __builtin_neon_XYZ overload is requested (e.g.
   we're not asking for a float32x4_t version when it only accepts integers. Since
   the __builtin_neon_XYZ intrinsics should only be used in arm_neon.h, relaxing
   this test and permitting AArch64 types for AArch32 should not cause a problem.
   The extra arm_neon.h definitions should be #ifdefed out anyway.
2. We check that intrinsics which take immediates are actually given
   compile-time constants within range. Since all NEON intrinsics should be
   backwards compatible, these tests should be identical on AArch64 and AArch32
   anyway.

This patch, therefore, merges the separate AArch64 and 32-bit checks.

rdar://problem/16035743
ARM NEON: use more flexible TableGen field for defs.

We used to have special handling for isCrypto and isA64 bits in the
NeonEmitter.cpp file (it knew the former was predicated on __ARM_FEATURE_CRYPTO
and the latter on __aarch64__ and went through various contortions to make sure
the correct intrinsics were emitted under the correct guard.

This is ugly and has obvious scalability problems (e.g. vcvtX intrinsics are
needed, which are ARMv8 only but available on both, yet another category). This
patch moves the #if predicate into the arm_neon.td file directly and makes
NeonEmitter.cpp agnostic about what goes in there.

It also deduplicates arm_neon.td so that each desired intrinsic is mentioned in
just one place (necessary because of the new mechanism for creating
arm_neon.h).

rdar://problem/16035743
ARM NEON: add vcvtX (with rounding mode) intrinsics to v8 ARM.

These instructions (well, the f32 ones) are supported on 32-bit ARMv8, not just
AArch64. Now that the arm_neon.td refactoring is complete, adding them is
surprisingly simple.

rdar://problem/16035743