Allow the trace output by mbed error to be conditional of NDEBUG.

[pan-]

This change disable any trace output by error when the application is compiled with NDEBUG.

Unlike assert, error will still crash/halt the execution of the application even if NDEBUG is enabled.
In that regard, its core behavior is preserved.

This change avoid the inclusion of printf and friends code in a binary when it is compiled with the macro NDEBUG enabled because a lot of driver code use error rather than assert.

The memory gain is non negligible: This is the differences with and without this change when mbed-os-example-blinky is compilef with NDEBUG enabled.

• Without the patch:

	GCC	ARMCC	IAR
RAM	11832	10152	7970
ROM	37008	26868	21266

• With the patch:

	GCC	ARMCC	IAR
RAM	11808	10152	7834
ROM	19852	20239	14600

• Difference

	GCC	ARMCC	IAR
RAM	-24 bytes (-0.2%)	0 bytes (0%)	-136 bytes (-1.70%)
ROM	-17156 bytes (-46.3%)	-6629 bytes (-24.7%)	ROM: -6666 bytes (-31.3%)

[pan-]

@0xc0170 @sg- Waiting for your comments.
I would like to know where the documentation around NDEBUG should be located.
For example, MBED_ASSERT use it but it is not documented.

[sg-]

I would like to know where the documentation around NDEBUG should be located.

I'd suggest we have 2, maybe 3 max build profiles that compliment this patch and have specific objectives and flags / macros used based on that. The never ending list of -o options should be wrapped into build profiles and documented. Something like -o size, speed, debug.

[0xc0170]

The never ending list of -o options should be wrapped into build profiles and documented

+1 for having profiles

This change-set looks good to me. We will discuss connection between NDEBUG and profiles once profiles get into the codebase, or?

@pan- 👍 for this