Refactor roles

[mohawk2]

This changes all roles from being eg Statocles::App to Statocles::Role::App.

Reasoning: the thing I found most confusing when digging into the code previously was the module Statocles::App::Role::Store - now that it's renamed to Statocles::Role::App::Store (and with the additional doc snippet saying it's effectively an extension of Statocles::Role::App), I find it far more comprehensible. Similarly, all other roles being called Statocles::Role::* is far more clear to my comprehension.

[coveralls]

Coverage remained the same at 92.162% when pulling ae716ad on mohawk2:refactor-roles into 2899da6 on preaction:master.

[preaction]

Would it make more sense to change the role interfaces (Statocles::App, Statocles::Page, Statocles::Deploy) into abstract base classes with methods that are required to be overridden. If that change was made, then Statocles::App::Role::Store would become Statocles::App::HasStore or WithStore (a base class to inherit from), which would, I think, achieve what you're trying to do here (de-confusify all the things!)

Otherwise, this seems to be substituting one arbitrary set of role naming conventions for another, but let me explain the conventions I'm using here to see if there are improvements we can make:

• Interface roles get the name of the interface. A Statocles Application is such because it consumes the role, there's no other way to do that. It's not optional, so it gets the most obvious name (Statocles::App, Statocles::Page, Statocles::Deploy). The Statocles::App::Blog is a Statocles::App, it just happens that Statocles::App is a role.
• Roles that apply only to a specific subset of classes get <parent>::Role::<name>. This points them out as applying only to the specific parent class/role.
• Generic roles that apply to any class go in a generic place, Statocles::Role::*. This has a drawback that some of these roles may now be confused with roles for the Statocles class, but since there's no real need/way to add roles to that class (yet), that's a hit I'm willing to take (using the Statocles object to interact with a Statocles site might be an interesting future development though...).

(That, and the more we could rely on Mojo::Base and the fewer Moo-specific features we use I think will be better for long-term performance reasons, except we do a lot of Type::Tiny coercions which are probably the bulk of the time we spend really and maybe I shouldn't be thinking about this when there are other fires to put out 😛)