Allow disabling definition of custom attributes

[jim-bcom]

PROBLEM

• In an attempt to reduce warnings in SolARFramework, we encountered several warnings emitted by GCC for each reference to a non-standard attribute to say it will ignore it.
  Ex:

warning: ‘xpcf::clientUUID’ scoped attribute directive ignored [-Wattributes]

• Unfortunately, there is no support for GCC to filter attributes to ignore.
  Here's the documentation for GCC 7 (the one we currently use):

-Wno-attributes
Do not warn if an unexpected __attribute__ is used, such as unrecognized attributes, function attributes applied to variables, etc. This does not stop errors for incorrect use of supported attributes.

• We could use this (in fact, I think we'll use that as a best effort option), but the trouble is that it will silence too much.
  For exemple, a typo when writing the name of a known attribute such as [[maybe_unused]] (but in this case this will probably emit a warning about an unused parameter (for example), so it won't stay unnoticed).

In GCC12, it becomes possible to specify such filter (doc):

-Wno-attributes=xpcf::clientUUID

But we're not going to be using GCC12/13 anytime soon.

SUGGESTED SOLUTION

• Currently, XPCF wraps a set of attributes using macros in helpers.h. The definition of theses attributes can be set to nothing thanks the the SWIG flag.
• We could use such a mechanism with another flag (since it's not related to SWIG) so that we can get rid of the warnings by removing the use of these attributes, since the gRPC attributes are not necessary for all of our projects, but only for the one that uses XPCF to generates gRPC clients and services.
• I've made a test locally with this flag: XPCF_DISABLE_ATTRIBUTES
  and this change to helpers.h:

#if !defined(SWIG) && !defined(XPCF_DISABLE_ATTRIBUTES)

NOTES

• I'm openning this as a discussion. I'm afraid it would introduce changes that are more related to our project than to XPCF.
• If you think this need might be generalized, we could discussed a way to do it properly, otherwise, it might not be worth integrating this change as a minor workaround specific to our project.