[clang] [CIR] Upstream `AddressSpace` support for `PointerType` (PR #161028)

[Henrich Lauko via cfe-commits]

xlauko wrote:

> > @bcardosolopes @andykaylor In general it might be worthwhile to align more with `ptr` dialect and its modeling of address spaces. Maybe even use `MemorySpaceAttrInterface` directly in out pointer type
> 
> I definitely like the idea of aligning better with other dialects, but it's not clear to me what that would mean. A few minutes browsing various in-tree dialects left me confused.
> 
> I see that there's an LLVM `AddressSpaceAddr` that uses the `MemorySpaceAttrInterface` but I only see this attribute attached to `ptr.ptr` in tests in the form `!ptr.ptr<#llvm.address_space<0>>`. If I'm reading this correctly, that's defining an opaque pointer in address space zero. This looks like what we're doing with `target<n>` address spaces.
> 
> But I also see that the GPU and AMDGPU dialects have their own address space attributes which look a bit closer to what we're doing currently with "language" address spaces. It's not clear to me how we'd transition from CIR to these. GPU has an enum defining `global`, `workgroup`, and `private`. We have `global` and `private` but it's not clear to me which of our other options would map to `workgroup`. For AMDGPU there are `fat_raw_biffer`, `buffer_src`, and `fat_structured_buffer`. I don't even have a guess there.

The origin of pointer dialect is that it started as extracting pointer representation from LLVM dialect as it might be usefull for other dialects too. See [RFC](https://discourse.llvm.org/t/rfc-ptr-dialect-modularizing-ptr-ops-in-the-llvm-dialect/75142).
So as we are ultimatelly lowering to LLVM IR, we should be able to easily map to pointer dialect representation.
I've seen there was a lot of updates of the dialect recently, so I am uncertain about how mature the things are. Maybe @fabianmcg or @joker-eph might have better insight?

https://github.com/llvm/llvm-project/pull/161028