Rename AddrSpacePtr

[maleadt]

This PR started as a rework of AddrSpacePtr, adding support for it to pointerset and pointerref, but while doing so I realized that (1) it isn't a good fit for Base (e.g. what to do at run-time with non-generic address spaces), and (2) AddrSpacePtr doesn't accurately reflect what this type does: These pointers are lowered to IR in a way that more closely resembles the underlying LLVM pointers:

julia> foo(x) = x
foo (generic function with 1 method)

julia> @code_llvm foo(C_NULL)

;  @ REPL[1]:1 within `foo'
define i64 @julia_foo_726(i64) {
top:
  ret i64 %0
}

julia> @code_llvm foo(reinterpret(Core.LLVMPtr{Nothing,0}, C_NULL))

;  @ REPL[1]:1 within `foo'
define i8* @julia_foo_817(i8*) {
top:
  ret i8* %0
}

i.e. more than just adding address space information, so it seems better to call it LLVMPtr.

I also considered lowering them to non-opaque types, i.e. i64* in the above example, but LLVM itself seems to be moving away from that it seems better not do. (Linked changes don't fully work)

PR also adds an ugly error when using invalid address space typevars -- no way to cleanly emit an error from there.

Open question: add support for pointerset/pointerref with LLVMPtrs, or keep these intrinsics in e.g. LLVM.jl? They currently live in CUDA.jl: https://github.com/JuliaGPU/CUDA.jl/blob/3af3e3104cc7baae2408598220395eff078e3f28/src/device/pointer.jl#L114-L180

Marked for backport so that we don't have the old name in any release.

cc @thomasfaingnaert

[vtjnash]

I think, if true, this would indicate it's a flaw in the abstraction level and we should consider removing this and doing it differently, as we generally try to keep LLVM as an implementation detail and avoid using it to define the behavior. However, since address_space is also present in clang and sparse, I think it's inaccurate to claim it's specific to LLVM.

[maleadt]

we generally try to keep LLVM as an implementation detail and avoid using it to define the behavior

Except for, e.g., llvmcall or the hard-coded use of LLVM intrinsics. It's exactly for those cases that we need to be able to emit something more closely to LLVM's representation (this type doing more than just adding an address-space property).

If Base ever has a need for address spaces, I guess we can always re-add Base.AddrSpacePtr that would still follow Julia's ABI.