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

[Dan Liew via cfe-commits]

delcypher wrote:


> "Extension" is definitely quite broad. What I meant are (basically) languages that are based off C or C++. Would you argue that `-fbounds-safety` fits into a set of OpenMP, OpenACC, CUDA, HLSL, Objective-C, and Swift?

In my opinion it fits in the set because it is a (pretty large) C language extension.
 
> > It's currently in the process of being upstreamed which is why it's small, but it'd be easier to split now than wait until it's reached a certain size, if we do want to split it eventually.
> 
> I did that a lot with other parts of `Sema`, and it's not that hard, unless it grows comparable to `SemaExprCXX.cpp` (which I consider unlikely to happen). I'd rather see this being upstreamed into the existing `Sema` structure as it has been planned all along, and use it as an input for the design of further `Sema` splitting, rather than committing today that `SemaBoundsSafety` is going to be a thing.

I don't agree with this approach. I outlined above why I think it makes a lot of sense to keep the `-fbounds-safety` Sema code in its own source file and blocking  doing that on a _potential future refactor_ that might never happen doesn't seem like a good idea to me.

If at some point we come up with some new design for Sema we can easily move the `-fbounds-safety` code out of its own source file (and class) and into the relevant locations required by the redesign. If the `-fbounds-safety` code is littered all over the other Sema files the "potential future refactor" could be much harder because finding all `-fbound-safety` code now is much more time consuming.



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