WTB STRICT_EXPECTED_CALL with format string

At the moment the output of the
```c
ASSERT_ARE_EQUAL(char_ptr, umock_c_get_expected_calls(), umock_c_get_actual_calls());
```

looks like this on my screen:

```code
Assert failed in line 11488 test setup MM3E12 Expected: [CONSTBUFFER_DecRef(0000000000000000)][bsdl_address_dec_ref(0000000000000000)][CONSTBUFFER_DecRef(0000000000000000)][bsdl_address_dec_ref(0000000000000000)][gballoc_free(0000000000000000)][gballoc_free(0000000000000000)], Actual: [bsdl_address_dec_ref(00000287FC45D3D0)][CONSTBUFFER_DecRef(00000287FC45F870)][bsdl_address_dec_ref(00000287FC45D5B0)][CONSTBUFFER_DecRef(00000287FC45F870)][gballoc_free(00000287FC4804D0)][gballoc_free(00000287FC45DD30)]
```

Which often at debug time leaves me wondering "sooo... exactly which of my 100 CONSTBUFFER_DecRefs were not matched... first... While it is discoverable which one it is, I would like to propose to change the signature of the `STRICT_EXPECTED_CALL` macro to include a `format_string` and a list of values, just like "printf" has.

Old code:
```c
STRICT_EXPECTED_CALL(CONSTBUFFER_DecRef(IGNORED_PTR_ARG));

=>

Expected: [CONSTBUFFER_DecRef(0000000000000000)]...
```

New code:
```c
STRICT_EXPECTED_CALL(CONSTBUFFER_DecRef(IGNORED_PTR_ARG), "expected in line=%d", __LINE__);

=>

[CONSTBUFFER_DecRef(0000000000000000)]("expected in line=11459")... //note the string "as printed by printf"

```

I believe this would allow the user to easily and quickly discover "which one" of the expected calls was not matched.

Best Regards,
Andrei Porumb

Start by tracing STRICT_EXPECTED_CALL and the ASSERT_ARE_EQUAL comparison involving umock_c_get_expected_calls() and umock_c_get_actual_calls(). Determine where expected-call text is assembled and how the macro could accept printf-style formatting values. Done means mismatched expected calls include the supplied formatted context without breaking existing call syntax.

Written by the indexing model from the issue text.