Add priv validation to database_grant provider

[reidmv]

The mysql database_grant provider currently has what is arguably a heinous design flaw. At present:

1. The 'privileges' parameter for the database_grant type, mysql provider, does not expect the same syntax as the mysql Grant command ('SELECT', 'UPDATE', 'DELETE', etc). Rather, it expects the user to supply column names used to store raw grants in the mysql.db or mysql.user tables internally ('Select_priv', 'Update_priv', 'Delete_priv', etc).
2. If a user supplies privileges => [ 'SELECT', 'INSERT' ] instead of privileges => [ 'Select_priv', 'Insert_priv' ], the provider fails silently and will continuously attempt to update the privileges with each successive puppet run. In the specific example provided, all privs for the user/db will be set to false since e.g. 'INSERT' does not match any valid privilege.

Unfortunately it doesn't look simple to modify the provider such that the intuitive SELECT, DELETE, etc. keywords can be used without changing existing behavior. Leaving that alone for now, it is pretty simple to add a validation function that will at least fail cleanly if non-functional privilege values are supplied that don't mean anything to the provider. If the user is trying to use valid MySQL Grant syntax, the new validation procedure will recognize this and suggest a correction. Hopefully giving users this kind of warning will clue them in to what kind of input the provider expects.

[hunner]

+1. Appears to add helpful error checking. It doesn't look like this could be done in the validate type method unless the type did execution of mysql statements on its own as per the query_*_privs methods.