When and what types should be reported as hex as well as decimal types?

In a way, this is continuation of #168, but updated with current state of reporting.

Currently, testing an `unsigned int` or `unsigned long`, that is larger than 255, prints out both decimal value of the variable and its hex representation. The same happens for `int`s, because integral literals have default type of `int` and won't be coerced to `unsigned int` because of expression decomposition.

Example
```cpp
TEST_CASE("reporting") {
unsigned long bits = 256;
REQUIRE(bits == 0x101);
}
```
outputs `failed: bits == 0x101 for: 256 (0x100) == 257 (0x101)`

However, this does not happen for `signed long`s: (notice the "l" behind the literal)
```cpp
unsigned long bits = 256;
REQUIRE(bits == 0x101l);
```
outputs `failed: bits == 0x101l for: 256 (0x100) == 257`

And for `long long`s (both signed and unsigned) nothing happens:
```cpp
unsigned long long bits = 256;
REQUIRE(bits == 0x101ll);
```
outputs `failed: bits == 0x101ll for: 256 == 257`

The question is, is this desired behaviour? I would expect at least `unsigned long long`s to be also printed in hex, and different behaviour between printing an `int` and a `long int` seems surprising unless you already know about limitations caused by the expression decomposition.

One thing we could do is to add `Hex` wrapper class, that does nothing except modifies how Catch prints it out, so user could specify that he always wants the results to be printed hexadecimally.

```cpp
REQUIRE(bits == Hex(0x101l)); // -> bits == 0x101ll for: ... == 0x101
```

Start by reviewing Catch2's current reporting behavior and the expression-decomposition limitations described in the examples. Compare output for unsigned and signed int, long, and long long values, then determine whether the intended scope is broader built-in-type support or a Hex wrapper. Done means the desired behavior and supported types are agreed and covered by appropriate tests.

Written by the indexing model from the issue text.