[clang] [clang-format] Add support for absl nullability macros (PR #130346)

[Ilya Biryukov via cfe-commits]

ilya-biryukov wrote:

Google C++ Style Guide and Abseil go hand-in-hand from Google's perspective. We are the stewards of both and we would prefer to keep the two in sync. We have opted to have the Google Style available as builtin in `clang-format` and have been sticking to that decision until now. I think it benefits everyone that each user of Abseil doesn't need to update their configuration files everywhere. We don't even have any downstream mechanisms to configure `clang-format` internally because we are committed to keep `clang-format` aligned with what we use.

#76239 was a former precedent where we got some mild pushback, but it ultimately landed. 

> The reason is that people wouldn't be able to turn off the special meaning if they wanted to use e.g. absl_nonnull as a regular identifier.

@owenca we deliberately use the prefixes to make sure it has almost zero chance of clashes with anyone else. What are the chances of somebody prefixing their code with `absl_`? I searched for `absl_nonnull` and found two results, both related to Abseil. 

> Imagine if we did this for every "toolkit"... we'd be inundated with add this/that etc... why can't people who use Abseil not add them to their .clang-format? Outside of google are that many people even using Abseil?
> Abseil itself doesn't even define them in their .clang-format file.
> This is a no from me.

People from Google were the original authors of `clang-format` and introduced google as one of default styles supported by the binary. We have never negotiated it explicitly, but having the ability to change the Google Style is definitely something we expected to keep going forward.

Do people on this thread feel it is a reasonable ask from Google? If not, could you elaborate and suggest a different governance model for the style defined by `clang-format -style=google`?
It is fairly important for us to clarify what folks are thinking about this and how we can move forward with these types of changes going further.

The question is mainly to @mydeveloperday @owenca, but also cc @HazardyKnusperkeks @rymiel who were mentioned in #76239.


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