MISRA 2004 rule 19.10: inside macros, surround each parameter usage with parentheses.

Help error detection by adding specific colors for test results. This
behavior is activated only when unity if compiled with UNITY_COLOR flag.

MinGW supports a limited form of weak symbols, with the restriction
that weak/default implementations need to be defined in the same
translation unit they are called from.  Strong/overriding symbols
may of course be specified in a different translation unit.

 Check for unsigned types, add 'or equal to' support
 Consolidate to one function to remove repeated code

This is simpler and more flexible than embedding C code in the Ruby options
(:suite_setup and :suite_teardown).  However, support for :suite_setup and
:suite_teardown is kept for backwards compatibility.

Several configurations are possible:
1. :suite_setup and :suite_teardown options provided and used.
2. :suite_setup and :suite_teardown options not provided (nil):
  2a. Weak symbols not supported; suiteSetUp() and suiteTearDown() are not called.
      It would be simpler to make user-provided functions mandatory in this case,
      but it could break some pre-existing test suites.
  2b. Weak symbols are supported and the stub implementations of suiteSetUp() and
      suiteTearDown() are called if there are no user-provided functions.
  2c. Weak symbols are supported but overridden by user-provided suiteSetUp() and
      suiteTearDown() functions.

The existing implementation was not very good:
 - It printed all very small values as "0.000000..."
 - It did not distinguish positive and negative zero
 - In some cases it printed extra garbage digits for single-precision values
   (e.g. 3.9e+30 was printed as 3.90000013+30)

Tests have been updated to check that we now match printf("%.6g") for
1,000,000 randomly chosen values, except for rounding of the 6th digit.

This fixes a compiler warning about a lossy conversion from long
unsigned int to int when compiling unity with gcc 6.3.1 and
the options -std=c89 -Wconversion -fsanitize=undefined

This fixes compiler warnings that clang produces with the
-Wdouble-promotion compiler option.

This only happens if double precision floating point numbers are
enabled.

The implicit double promotion occurs because numbers of type UNITY_FLOAT
are passed into UnityPrintFloat, which expects const UNITY_DOUBLE.

This commit fixes it by explicitly casting to UNITY_DOUBLE.

There was a mismatch of definition and declaration of UnityPrintFloat
and this commit aligns both on const UNITY_DOUBLE, but then inside it
actually uses a positive version of the variable only.

Used clang-format, which produces noise on stuff you don't care about
and requires setting it up to match the existing code base. Kept the
potentially useful changes, discarded the rest, some manual tweaking
required. It did catch lots of pesky indentation mistakes.

This reverts commit ee382194.
Removing these changes per coding standard, after the code review

Move longjump inside caller, to functions returning 'void'
This single function needed to change to allow optional setjmp.h

The setjmp calls are all in TEST_PROTECT() already

Defensive coding

Originated from commit c6dc96f3 but are rarely used and not in math.h
Removes float to double promotion warning and simplifies the code
'gcc -std=gnu99 -Wdouble-promotion' spits out these warnings

Remove UNITY_FIXTURES option, which was probably not doing what was
originally indended. It was suppressing the test name even in quiet mode.

Revised internal type naming scheme to better sandbox Unity away from everything else. Sure, short was nice, but not at the expense of naming collisions.

Takes about 10 minutes to run all floats, so split into 3 tests for parallel
running later. This was useful during development for finding hard corner cases
and getting the routine to high quality. Off by default.
Note that all floats 16.0 and up can be represented uniquely (in this format) and will
round-trip back to the exact same float with sscanf(). This property is true for
UnityPrintFloat, despite a few rounding error cases, it will produce output identity.

Better comments and refactor on round ties to even
Add upper threshold value on round to even feature since numerical precision issues
start to give approximations when dividing one large double by another. When tested
on float values, using 1e22 gave the fewest rounding errors.

Fix warnings from gcc. Some float constants do not behave well in existing tests.
Add casts where conversions could be imprecise.