Fix diagnostic for @c enum T: Int128.

[grynspan]

This PR fixes the incorrect diagnostic when an integer type known to Swift but not to C/Objective-C is used with an @c or @objc enum:

@c enum T: Int128 {} // 🛑 '@c' enum raw type 'Int128' is not an integer type

The diagnostic now reads:

🛑 '@c' enum raw type 'Int128' must be an integer type expressible in C

(Substituting "Objective-C" when @objc is used.)

[grynspan]

@swift-ci test

[slavapestov]

Should we factor this out into common utility?

[grynspan]

I think if there are other examples yes, otherwise "not until there are other examples."

[hnrklssn]

This seems like it should be supported. Since a while back we map __int128 to CInt128, which is a type alias for Int128:

commit 1fe7f685b5a1e2ab588f039877432cf9541f93fb
Author: John Hui <j-hui@apple.com>
Date:   Thu May 14 20:58:50 2026 -0700

    [cxx-interop] Import __int128 as CInt128
    
    Swift gained native Int128 / UInt128 types in SE-0425, but the plumbing
    for bridging them across the C/C++ boundary was incomplete. CInt128 and
    CUnsignedInt128 were never added to CTypes.swift, even though
    BuiltinMappedTypes.def has been mapping __int128 / unsigned __int128 to
    those names since 2013. Without the typealiases, every C declaration
    mentioning __int128 was silently dropped at import time.
    
    This patch adds the CInt128 and CUInt128 type aliases to CTypes.swift
    for forward interop, and also adds the Int128 -> __int128 mapping in
    PrintAsClang and IRABIDetailsProvider for reverse interop.

Even if we don't end up supporting @c enum T: Int128 right away, it feels weird to say the type is not expressible in C.

[grynspan]

I'm happy to bikeshed the spelling. However, at least as of the toolchain I was using, it wasn't supported, so if it's a very new feature, great—and we should still tweak the diagnostic because there are other integer types in Swift that aren't valid as enum bases in C. At least, that's my take.