Add the CTypes module for common C type aliases

[HertzDevil]

See #13504 (comment).

[straight-shoota]

thought: I was wondering if module C could be an option as it allows to conveniently write C::Char. But that would likely cause confusion because A, B, C are commonly used as stub constants.

Importing with a local alias (private alias C = ::CTypes) would be of similar convenience.

(ref #13504 (comment) ff.)

[straight-shoota]

question: Is this actually true? Isn't Pointer#address currently 64-bits on all architectures?

[HertzDevil]

It is more like "CTypes::UIntPtrT.new(ptr.address) should never raise OverflowError" on any target. And this should be true even if ptr = Pointer(Void).new(UInt64::MAX) on a 32-bit platform, as LibLLVM.build_int2ptr will zero-extend or truncate the address.

[ysbaddaden]

As stated in the issue: I fail to see the point. What's wrong with LibC::SizeT?

[Blacksmoke16]

One of the big benefits of this IMO is having it actually show up in the API docs. Tho a related problem of that is the API docs are essentially going to be "wrong" in that they'll only be applicable to whatever built them.

An alternative would be having something in the reference material for this.

[Sija]

If the docs are being arch specific it might lead to confusion, reference material would be IMO clearer in this regard.

[straight-shoota]

@Blacksmoke16 Good point. With normal constants we can actually have the generic definition including the macro code that decides the value based on different flags (example File::NULL).
But this doesn't work with alias (Maybe it could, though? I think the API docs for aliases could be improved 🤔).

Anyway, the doc comments in this PR are pointing out the options, so I don't think it's a big issue.

[HertzDevil]

With alias Int = {% if ... the whole condition shows up in the docs but Int cannot be used in top-level macros (it would evaluate to that MacroIf node). With {% if ... %} alias Int = ... it is the opposite.