Don't export class methods by default

[aherrmann]

The methods of the capability type-classes (e.g. put_ from HasState) are not meant to be used directly, currently this is documented in their haddocks. With the separation of user facing modules and internal modules, such as Capability.State and Capability.State.Internal.Class, it is possible to not export them from the user facing modules.

We should consistently separate user facing from internal modules (e.g. Capability.Writer vs Capability.Writer.Internal.Class) and not export class methods in the user facing modules.

---

cc @mrkkrp

[aspiwack]

(I don't know what the class would not be in Capability.Writer.Internal)

The class methods are not an internal thing however, they very much matter if you need to define manual instances of the capabilities.

It may be worth it not to export them in main modules because it can be considered avanced usage, and, possibly, it may make the documentation more approachable (though, a typeclass without methods may throw people off as well). But in that case, the type class should be exported in its entirety in some non-internal module (I don't have a name for this module at this point).

[mrkkrp]

For consistency, I'd expect every capability to have an internal module.

[aspiwack]

I don't think internal modules should have any sort of consistency. They are, by definition, not part of my API. Rather, use-at-your-own-risk extras.

[mrkkrp]

Why not have consistency in extras too :-D