Explicitly forbid inheriting SME keyword attributes

[acoplan-arm]

This patch aims to clarify the interaction between SME keyword attributes and a common compiler extension which allows type attributes to be inherited given a pair of subsequent declarations D1, D2 where D1 has type attributes and D2 has none.

The patch just explicitly spells out behaviour which (in my understanding) is:

• the intent of the existing specification
• existing clang behaviour
• intended GCC behaviour (which has regressed in GCC 16, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122483). The hope is that the new wording will help smooth the way for this regression to be fixed in GCC 17.

The SME keyword attributes section says:

Except where noted otherwise, function types that have an attribute
are incompatible with function types that do not.

I believe the intent here was for this incompatibility to extend to compiler extensions which currently allow code such as:

void f(void) [[attr1, ..., attrN]];
void f(void);

as a convenience for situations where f is likely to be included from a header file, and the user doesn't want to have to write out all of the attributes in a local redeclaration.

E.g. the following C code is currently accepted by both GCC and clang:

void f(void) __attribute__((aarch64_vector_pcs));
void f(void); // accepted

but if we switch the order of the declarations, it is (correctly) rejected by both compilers:

void g(void);
void g(void) __attribute__((aarch64_vector_pcs)); // rejected

I believe the intent of the ACLE for SME keyword attributes was always to reject code such as:

void f(void) __arm_inout("za");
void f(void);

i.e. that this convenience feature should not apply to those SME keyword attributes that affect type identity. The rationale is along the lines that the above is logically equivalent to something like:

void f(za_state &);
void f(void);

which should be considered ill-formed in the same way that e.g.:

int f(int x);
void f(void);

is.