Add support for arbitrary method specifiers

[Flamefire]

As requested in #48 this adds support for passing method specifiers.

This is a breaking change for the MOCK_METHOD_EXT macro which was in the detail namespace but seemingly used by users without variadic macro support. Those codes will stop to compile.
Fix is a literal replacement to MOCK_METHOD so I didn't keep the compatibility in favor of a better interface.

The test case shows the intended usage nicely, so I copy it here:

    MOCK_METHOD(m1, 2)
    MOCK_METHOD(m2, 2, void(int, float))
    MOCK_METHOD(m3, 1, void(int), m3)
    // New:
    MOCK_METHOD(m14, 2, void(int, float), m14_int_float, ())
    MOCK_METHOD(m14, 2, void(int, int), m14_int_int, (override))
    MOCK_METHOD(m14, 1, void(int), m14_int, (override, const noexcept override))
    MOCK_METHOD_EXT(m15, 0, (& override, && override), void())
    MOCK_METHOD_EXT(m12, 0, (noexcept override))
    MOCK_METHOD_EXT(m13, 0, (&&override))

This shows the current usage and how it can be extended to add any number of specifier combinations.
It is likely that when using specifiers a custom identifier/name is required. I experimented with a MOCK_METHOD_OVERLOAD as described in the issue but quickly found that it is just another optional parameter of MOCK_METHOD so no new macro is required.

MOCK_METHOD_EXT is now used to easily add specifiers. In the issue I thought about naming it MOCK_METHOD_MOD or similar but settled with EXT which to me sounds better.
It allows using specifiers as easily as regular usage with the MOCK_METHOD macro, i.e. without using a signature and/or identifier by default but as options.

To reduce boilerplate future work could maybe automatically add override to each generated method and/or automatically derive noexcept for "easy" cases.

Any opinions on the current design so far? @mat007 @sebkraemer

Note on the implementation: Empty tuple elements are required to support the case of no specifiers, i.e. non-const etc. This allows e.g. MOCK_METHOD_EXT(m, 0, (, const, &, &&,), void()) to generate all 4 variants in one go. However MSVC has the warning C4003 when passing an empty argument to a function expecting a parameter and BOOST_PP does that during tuple unpacking to remove one item at a time. Hence the need for a custom FOR_EACH loop implementation.

[mat007]

@Flamefire this looks pretty good!

[coveralls]

coverage: 99.596%. remained the same
when pulling 86d6ae3 on Flamefire:modifier-support
into 8151fe2 on mat007:main.

[Flamefire]

Ok, and it passes for GCC/Clang on CI now.
The appveyor build is missing though and I can't access it to check why. @mat007 Can you check why it isn't running and not reporting anything at all please? MSVC is quite different with respect to macros so we should run those tests there too.

This also needs a documentation update. Is http://turtle.sourceforge.net autogenerated or anyhow updated from the repo?

[mat007]

Is http://turtle.sourceforge.net/ autogenerated or anyhow updated from the repo?

I think it’s uploaded manually by me after each release.

[mat007]

The appveyor build is missing though and I can't access it to check why.

The AppVeyor App was never installer on this repo, I’ve fixed that.
You may have to re-push to your branch branch or something, to trigger it now though.