Support user-defined lifted types

[propensive]

This feature has several advantages over v0.6.1:

1. Magnolia would no longer need to be a runtime dependency of any libraries which use it,
2. implicit evidence (of some type other than the typeclass being derived) could be requested for each parameter,
3. runtime and compile-time performance could be improved by reducing garbage generation

The macro currently instantiates CaseClass, SealedTrait, Subtype and Param instances which it passes to the user-defined method, combine. Magnolia provides fully-functional versions of these types. That is, including all the features which may be utilized in any given derivation, regardless of whether they are actually used or not.

However, there is scope for alternative implementations of these types to be used, and it should be possible for users to abstract over the instantiation of these types in general ways, for example by resolve additional typeclass instances on the type of the parameter (which is not currently possible from within the combine method definition, as the parameter type is existential by that point).

I propose to give users the option of providing their own implementations of these types, to be instantiated by new methods provided on the derivation object, namely,

• param,
• caseClass,
• sealedTrait, and
• subtype

As with combine and dispatch, the signatures of these methods would not have to adhere to a fixed interface (in the object-oriented sense), and could take additional type parameters or implicit parameters, but would be invoked by the macro which would inspect their parameters' names, and supply values only to those parameters in the signature. Any parameters (e.g. support for default values) not listed as the parameter would not be generated.

The first advantage would be that a number of ephemeral objects which exist only for covariant or only for contravariant typeclasses would not need to be instantiated for all cases, even when they are not used in the derivation. This should be beneficial for both compile time and runtime performance.

The second advantage would be that user-defined classes could be used in preference to Magnolia's default implementations, thereby obviating the need for Magnolia to be a runtime dependency. Given the library is likely to be useful for a number of other projects, the risk of a diamond dependency problem could be eliminated, while for application (i.e. non-library) developers, the tersity of the status quo would apply.

The existing API would remain unchanged if users did not provide any of the custom methods.

[SystemFw]

Nice to see this being worked on :)