[clang] [Bounds Safety][NFC] Add `SemaBoundsSafety` class and move existing Sema checks there (PR #98954)

[Dan Liew via cfe-commits]

delcypher wrote:

> The separations we've been making so far in Sema have been at a higher level of granularity than this proposal. Vlad was calling it "language extensions" but perhaps a different way to phrase it would be "unique language dialects". e.g., Objective-C is its own language, but it's technically an extension of C. Similar for things like OpenMP, etc. I don't think bounds safety is the same kind of extension in that regard; it's a handful of features allowing for extra diagnostic checking more than it's a unique language.

Thanks for clarifying. I would describe`-fbounds-safety` as a lot more than extra diagnostic checking, it also injects runtime checks and its programming model adds restrictions that make C feel quite different. I'm not really sure that counts as a dialect but I guess it doesn't matter now given that I'll be going with a different approach.

Out of curiosity, how does the current division of Sema fit into the "unique language dialect" classification? I've noticed there are a bunch of architecture specific Sema classes (e.g. `SemaRISCV`, `SemaX86`) and those don't really fit the classification.

>  For example, thread safety analysis can be described in exactly the same way, so should it be split off too? If we keep doing that, will splitting semantic object by language feature scale? What's the criteria for when a language feature should or should not be split? I think we can side step all of this for right now.

Interesting question. I guess it depends on the size of the language feature and given that almost none of `-fbounds-safety` is currently upstream it is very difficult for you to make an informed decision in this particular case. So, yes let's side step this for now. We can always revisit it once a significant portion of `-fbounds-safety` is upstream.

> The goal is to provide some layering within Sema to help break it up more. e.g., the base layer is C and C++ needs, but then there's a layer for Objective-C needs, a different layer for OpenMP needs, etc. This helps make it more clear where dependencies lie between the large-scale different semantic components. Bounds safety isn't really a "layer". Does that make some sense?

Mostly, but I have some doubts about the "Bounds safety isn't really a layer" part but let's delay dealing with that until more of the implementation is upstream.

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