<bsd.own.mk> variable naming convention for compiler warnings

Hi fellow toolchain people.

I propose to adjust the naming convention (*) used for variables used to
suppress compiler warnings in <bsd.own.mk>, the Makefiles, and
tools/compat:

1. Share the same variable for Clang and GCC; if the compiler supports
   a given option, just use it, especially if it's for suppressing
   a particular newer compiler warning in older code, assuming
   that it won't be an issue.

2. The naming convention is "CC" + the compiler flag converted to upper
   case, - and = changed to _ a la   tr -=a-z __A-Z.

3. For variable naming purposes, treat -Werror=SOMETHING as -WSOMETHING,
   and -Wno-error=SOMETHING as -Wno-SOMETHING (usually from Clang).
   Test the actual name, but construct the variable name without "-error=".

The existing <bsd.own.mk> variables will be renamed to:
- CC_WNO_ADDRESS_OF_PACKED_MEMBER
	For -Wno-address-of-packed-member (gcc 9)
	and -Wno-error=address-of-packed-member (clang)
	Replaces CLANG_NO_ADDR_OF_PACKED_MEMBER,
	CC_NO_ADDR_OF_PACKED_MEMBER, 
	GCC_NO_ADDR_OF_PACKED_MEMBER.
	Note: changing 'NO_ADDR_' to 'NO_ADDRESS_'.
- CC_WNO_CAST_FUNCTION_TYPE
- CC_WNO_FORMAT_OVERFLOW
- CC_WNO_FORMAT_TRUNCATION
- CC_WNO_IMPLICIT_FALLTHROUGH
- CC_WNO_MAYBE_UNINITIALIZED
- CC_WNO_RETURN_LOCAL_ADDR
- CC_WNO_STRINGOP_OVERFLOW
- CC_WNO_STRINGOP_TRUNCATION


tools/compat/configure.ac will be extended to detect all the variables
and provide appropriate overrides in the generated defs.mk used
by the tools build.


More background:

Currently we have the naming convention:
- GCC_NO_SOMETHING	# gcc version specific warnings disable
- CLANG_NO_SOMETHING	# clang version specific warnings disable
- CC_NO_SOMETHING	# union of GCC_NO_* or CLANG_NO_* where common
where "SOMETHING" is a name similar to (but not always the same as)
the -Wno-SOMETHING flag to gcc / clang.

I renamed NO_ADDR_OF_PACKED_MEMBER to CC_NO_ADDR_OF_PACKED_MEMBER to
keep the "NO_" variable prefix for other uses in the build system.

In other projects I've found it useful to name the variable much
closer to the flag being detected.
E.g.
-  -funroll-loops	CC_FUNROLL_LOOPS
-  -Wno-cookie		CC_WNO_COOKIE

In tools/compat I recently added support for determining if the host
compiler supports a given -Wno-SOMETHING, and then override the
relevant bsd.own.mk variable in defs.mk, to avoid warnings
from clang about unknown options in the tools build.


Thoughts?


Luke.


(*) Naming being one of the two hard problems, per
https://martinfowler.com/bliki/TwoHardThings.html
	There are 2 hard problems in computer science:
	cache invalidation, naming things, and off-by-1 errors.