Ignore commit messages if they match regular expression

[ulyssesrex]

Addresses mmozuras#14.

See the README diff for a user-facing explanation of the changes in this PR, starting with "Ignoring commits." It includes details on how to configure poper settings to ignore certain commit messages.

Purpose

Some commit messages are automatically generated. From this very repository, we have an example:

Merge pull request #8 from BaneOfSerenity/config-fix

That commit message summary has 52 characters.

If poper runs either of the following checks on that commit, it may fail:

• character_limit
• summary_character_limit

Merge commit messages (for example) are automatically generated by concatenating several strings, one of which is the name of the merged branch. Since the branch name may be arbitrarily large, each time you merge a branch into yours and generate a merge commit, you run the risk of that commit failing a poper check.

There may be reasons why someone would want to keep the long merge commit messages in the repository as-is, while also enforcing length limits on commit messages which developers have directly authored.

Approach

This PR adds related settings to Poper::ConfigFile::EMPTY. Rules may then access these settings via methods that are dynamically created and callable on the @config instance variable.

The settings themselves provides strings that can be passed to the Ignore::MatchingPattern interface, which can be included in any Rule. This interface provides a should_ignore? method which may be used to return early from a check if it returns true.

I felt Rule::Ignore::MatchingPattern deserved its own folder because there could be reasons to ignore a rule check other than a commit message matching a pattern.

A Regexp descendant class has been created to parse non-String values that could be passed to the Rules from the user configuration.

Hopefully this approach provides room for future expansion of regular expression matching capabilities (enforcing that a commit message does match a pattern), as well as expanding which rules may be ignored in certain circumstances.

Further considerations

No pre-existing poper configurations should be affected by these changes.

[ulyssesrex]

Closing in favor of mmozuras#17.