New Resource interface

[krimdomu]

Hello,

this is the new resource interface based on Moose and Roles.

Things the new interface adds (or helps with):

• export of resources to main namespace (or not)
• easy provider multiple kinds of the same resource (no code needed to test which parameter was set and which not, Rex::MultiSub handles it)
• validation of parameter list. it uses MooseX::Params::Validate to validate parameters. So it is possible to validate against all kinds of variable/object types. and also easily provide defaults.
• usage of Moose-Roles so that the provider of a resource (the thing which does the real work) can tell rex which ensure options it can handle (possibility to have sane error messages)
• common interface for things like: on_change, timeout, only_if, on_, before_, after_*, ... (meta resource parameters)
• every resource is easily extendable with providers. for example the file() resource has a POSIX provider to write files on linux/unix like filesystems. If you want to write files on webdav you just need to implement a provider and append it to the resource call in the Rexfile.
• better reporting facilities (the reporting is not handled by the Resource)

Feel free to comment.

If you want to see more examples, you'll find some pocs on my private repo (run, file, pkg, kernel):
https://github.com/krimdomu/Rex/tree/refactor/resource-base/lib/Rex/Resource

Currently it only has one downside: It doesn't run on Windows. Windows can't handle timeouts. (Which also doesn't work with the current version, but i use the module Time::Out and because of this it doesn't start on windows)

[ferki]

@krimdomu: I've done some initial review, and I'd like to provide you some feedback before it gets merged :)

1. It currently fails t/resources.t and t/param_lookup_resource.t tests. I didn't take a closer look yet, but this obvisously needs to be fixed.
2. I find the whole change too big to easily comprehend for a full review. Do you think it would be possible to split it up into a few smaller changesets instead? Perhaps one PR could deal with the changes to the resource interface, and another one with migrating the firewall resource (and/or more resources).
3. Are those changes backwards-compatible (is it a second interface next to the existing one, or replacing that)? Does it break any of the existing resource implementations?