Refactor/module info 2

This is the more destructive changes to the original implementation. This provides a DSL for defining where modules are supported. The good things about the implementation is that if you leave off something like "version", then it assumes all versions. This is useful for say Debian where all the modules are the same across all the versions.

This hopefully creates the more  flexible/readable interface you were hoping for in this section of code.

```
modules for: { platform_family: "debian", httpd_version: "2.2" },
  are: %w(
    actions alias asis auth_basic auth_digest authn_alias authn_anon
    authn_dbd authn_dbm authn_default authn_file authnz_ldap authz_dbm
    authz_default authz_groupfile authz_host authz_owner authz_user
    autoindex cache cern_meta cgid cgi charset_lite dav_fs dav_lock dav
    dbd deflate dir disk_cache dumpio env expires ext_filter file_cache
    filter headers ident imagemap include info ldap log_forensic mem_cache
    mime_magic mime negotiation proxy_ajp proxy_balancer proxy_connect
    proxy_ftp proxy_http proxy_scgi proxy reqtimeout rewrite setenvif
    speling ssl status substitute suexec unique_id userdir usertrack
    vhost_alias
  ),
found_in_package: -> (name) { "apache2" }
```

This is the magic right here. You pass a hash of criteria, the key, and we look through each module list entry (or lock) and see if the key meets the criteria of the lock. The nice part is the key can have more fields than the lock and a match is still made. Providing the ability to fall through when `version` or `platform` may not be important when finding the module list and instead the `httpd_version` and the `platform_family`.