Create nested-equals matcher

[gilvan-reis]

Create nested-equals function to match nested maps with equals and providing a documentation closer to the code about the nested behavior for matchers.

Closes #217

[gilvan-reis]

Feel free to suggest a better explanation here

[philomates]

Maybe something more like the following which explains it in broader terms and mentions the fact that there are defaults that are being overridden:

A matcher that always uses the equals matcher at every level of nesting. Useful given that matchers usually only change the first level of the data they are applied to, leaving nested data to use the default matcher of that type of data. For instance, this can be used to assert that any nested map has exactly the same keys and matching values as provided in the expected, and no more.

Note: this excludes functions, which continue to be invoked as predicates instead of compared via the equals matcher

[gilvan-reis]

I have added regex exclusion too. Feel free to correct me if I'm wrong

[philomates]

other possible names for deep-equals:

• equals-as-default: has the benefit where default keys the reader to the fact that there is a default that isn't always equals.
• always-equals
• strict

As a note, the midje implementation had a similar thing, match-equals, but the name isn't so great because it conflates the match construct with the combinators.

[gilvan-reis]

I think we should have equals in the function name, so I decided to follow with strictly-equals WDYT?

[philomates]

Nice, thanks for the PR!

Can you add the matcher to the list in the readme?: https://github.com/nubank/matcher-combinators#built-in-matchers

Also the https://github.com/nubank/matcher-combinators#overriding-default-matchers mentions a match-with example that could be replaced with strictly-equals. Could you add a line there that says "For convenience we've also added this as a built-in matcher called strictly-equals?

[philomates]

Maybe something more like the following which explains it in broader terms and mentions the fact that there are defaults that are being overridden:

A matcher that always uses the equals matcher at every level of nesting. Useful given that matchers usually only change the first level of the data they are applied to, leaving nested data to use the default matcher of that type of data. For instance, this can be used to assert that any nested map has exactly the same keys and matching values as provided in the expected, and no more.

Note: this excludes functions, which continue to be invoked as predicates instead of compared via the equals matcher

[gilvan-reis]

@philomates I have replaced the match-with example in the README. Feel free to inform me if you want to stay with both instead

[gilvan-reis]

I have also added the versions changes to be validated

[scottbale]

LGTM but I'll defer to @philomates's review

[philomates]

Looks good!
Was mulling the name over a little bit more and nested-equals came up. I like it because it refers to nesting, which is really where this differs from the default. Like the matcher used for functions and regex stays the same, but for any nested/container datastructure equals is used instead of whatever default.

What do you think? Or should we just stick with this?