Increase test coverage for `@free`, `@module` and `@tagless` macro annotations

[raulraja]

As suggested by @diesalbla we should provide a wider range of compilation tests for cases related to the expanded @free, @module and @tagless macro annotations. This is necessary to ensure things like adding multiple type args in traits, concrete members and other valid scala features to traits do not affect the expansion and their properties are preserved. This will also help us boost code coverage which currently is below desirable.

[diesalbla]

Also, an important goal of the test coverage for the macros should be to illustrate, in as small as possible examples, the features that are expected to be provided by the macros in particular. These features should try to fit in the Scala language in general.

Some of the issues that the tests on the macros should consider are the following ones:

• @free or @module should work correctly, irrespectively of whether the traits are a top-level definition (i.e. inside a package, including the _root_ package); or inside a container object, or inside a class. This dimension was the actual cause for issues #221 and #185.

• The @free annotation should allow defining derived methods using the basic operations and the methods from the Functor, Applicative, and Monad typeclasses in cats. This should also be possible whether using the method names, binary operators (from cats.syntax), or for-comprehensions.

• The @module or @free annotations should allow for additional type parameters, both in the trait itself, in the request methods, such as: @free trait Ann[A] { def bob[B] }