Attribute spelling policy

[Aaron Ballman via cfe-commits]

Attributes come with multiple spelling flavors, but when it comes to
adding new attributes that are not present in other compiler tools
such as GCC or MSVC, we have done a poor job of being consistent with
which spelling flavors we adopt the attributes under. Some of our
attributes are specified with only an __attribute__ spelling (about
100), while others are specified with both __attribute__ and
[[clang::XXX]] (about 30), and still others are specified as only
[[clang::XXX]] attributes (only 1). This puts additional burden on
developers to remember which attributes are spelled with what syntax
and the various rules surrounding how to write attributes with that
spelling.

I am proposing that we take a more principled approach when adding new
attributes so that we provide a better user experience. Specifically,
when adding an attribute that other vendors do not support, the
attribute should be given an __attribute__ and [[clang::]] spelling
unless there's good reason not to. This is not a novel proposal -- GCC
supports all of their documented __attribute__ spellings under a
[[gnu::XXX]] spelling, and I am proposing we do the same with our
vendor namespace.

Assuming this approach is reasonable to the community, I will add a
CLANG spelling that behaves similar to the GCC spelling in that it
automatically provides both the GNU and CXX11 spellings as
appropriate. There are some attributes for which a [[clang::XXX]]
spelling is not appropriate:
  * attributes that appertain to function declarations but require
accessing the function parameters, such as disable_if or
requires_capability
  * attributes with GNU spellings whose use is discouraged or
deprecated, such as no_sanitize_memory
  * attributes that are part of other vendor specifications, like CUDA or OpenCL
These deviations are reasonable, but should be documented in Attr.td
near the Spelling definition for the attribute so that it's explicitly
understood why the spelling differs.

Additionally, I intend for the proposed CLANG spelling to be extended
in the future to more easily expose [[clang::XXX]] spellings for
attributes intended to be used in C (with
-fdouble-square-bracket-attributes) as well as C++.

As always, feedback is welcome!

~Aaron