[clang] [BoundsSafety] Add `-fexperimental-bounds-safety` CC1 and language option and use it to tweak `counted_by`'s semantics (PR #92623)

[Dan Liew via cfe-commits]

delcypher wrote:

@AaronBallman 
> I'd like to understand why we need a flag for this rather than changing the behavior of `-fbounds-safety`. (I'd like to avoid a proliferation of flags unless this flag is going to gate more changes in the near future.)

This is a good question so let me first give you some context.

When I originally landed #90786 (which allowed `counted_by` to be used on pointers in structs) it exposed an issue in code in the Linux kernel that was using the `counted_by` attribute incorrectly (see https://github.com/llvm/llvm-project/pull/90786#issuecomment-2118416515) which was now caught by an error diagnostic that I added. To unbreak the build of the Linux kernel I temporarily downgraded the error diagnostic to be an warning to give the kernel authors time to fix their code.

This downgrading of the error diagnostic to a warning is a departure from the intended semantics of `-fbounds-safety`. This is the very first time in upstream where we have needed to distinguish between `-fbounds-safety` being on-vs-off. So this seemed like a good opportunity to upstream the bounds-safety CC1 flag which we will need to have upstream anyway for future patches.

To be clear about the behavior of `-fbounds-safety`. It **doesn't need to be changed, it's already correct**.  It's existing uses of the `counted_by` attribute that are wrong.

To your point about proliferation of flags. `-fexperimental-bounds-safety` **is the CC1 flag** that guard the `-fbounds-safety` feature in our internal Clang (modulo the name, we don't have the `experimental-` prefix internally). It will **need to exist** as we continue upstream more of our implementation that depends on this flag. 

Stepping back a bit. The downgraded error diagnostic is a temporary measure so eventually this diagnostic will be an error again in all cases (`-fbounds-safety` on or off). So adding the CC1 flag on the basis of something that's temporary might be considered questionable. If you really have a problem with this I can abandon this PR and we can land the `-fexperimental-bounds-safety` CC1 flag later when it is needed to guard something more permanent. 





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