Definition of __(U)INT64_TYPE__ on riscv64 is inconsistent with other targets

Nobody has claimed this yet.

On 32-bit systems, Clang defines `__INT64_TYPE__` and `__UINT64_TYPE__` using `long long`:

```
$ i686-unknown-cloudabi-cc -dM -E - < /dev/null | grep INT64_TYPE
#define __INT64_TYPE__ long long int
#define __UINT64_TYPE__ long long unsigned int
$ armv6-unknown-cloudabi-eabihf-cc -dM -E - < /dev/null | grep INT64_TYPE
#define __INT64_TYPE__ long long int
#define __UINT64_TYPE__ long long unsigned int
```

On 64-bit systems, it chooses plain `long` instead, as this is the smallest primitive type that is sufficiently large:

```
$ x86_64-unknown-cloudabi-cc -dM -E - < /dev/null | grep INT64_TYPE
#define __INT64_TYPE__ long int
#define __UINT64_TYPE__ long unsigned int
$ aarch64-unknown-cloudabi-cc -dM -E - < /dev/null | grep INT64_TYPE
#define __INT64_TYPE__ long int
#define __UINT64_TYPE__ long unsigned int
```

For RISC-V, we always use `long long`.

```
$ riscv32-unknown-cloudabi-cc -dM -E - < /dev/null | grep INT64_TYPE
#define __INT64_TYPE__ long long int
#define __UINT64_TYPE__ long long unsigned int
$ riscv64-unknown-cloudabi-cc -dM -E - < /dev/null | grep INT64_TYPE
#define __INT64_TYPE__ long long int
#define __UINT64_TYPE__ long long unsigned int
```

Though this is technically correct, I've seen some code break as a result of this, especially when code expects that `uint64_t` and `size_t` can be mixed on riscv64.

Start by locating the RISC-V target definitions responsible for Clang's __INT64_TYPE__ and __UINT64_TYPE__ macros. Reproduce the issue with the riscv32 and riscv64 preprocessor commands shown, then compare their output with x86_64 and aarch64. Done means riscv64 follows the intended 64-bit target convention without breaking riscv32.

Written by the indexing model from the issue text.