Fix matcher logic to work with complex strings

[santino]

Hey @MicheleBertoli,
I'm back with a new PR, once this is merged I will also raise another one to address eslint/prettier formatting clashes.

Introduction

The matching logic has recently been refactored using jest toEqual in order to support undefined and jest asymmetric matchers in addition to strings and regexp as part of #148.

The issue

For strings and regexp #148 introduced comparison with the asymmetric matcher stringMatching which, according to the documentation, supports strings and regexp but this matcher actually transforms strings into regexp.
This creates issues with complex strings like '1px solid rgba(0,0,0,.125)' which gets transformed into /1px solid rgba(0,0,0,.125)/.
In this case a test like this would always fail

// Pure jest example
expect('1px solid rgba(0,0,0,.125)').toEqual(expect.stringMatching('1px solid rgba(0,0,0,.125)'))

// jest-styled-components example (border rule applied is equal '1px solid rgba(0,0,0,.125)')
expect(component).toHaveStyleRule('border', '1px solid rgba(0,0,0,.125)')

This means that stringMatching cannot actually be relied for strings comparison.

The fix

The matcher logic has been simplified, rather than using a whitelist approach for the new cases (e.g. undefined and asymmetric matchers) we are now just using stringMatching when a regexp expectation is passed otherwise we can use directly the expected value as argument for toEqual.

This allows a correct comparison for strings and regexp whilst still supporting undefined and jest asymmetric matchers.

NOTE: A test has been added to make sure this scenario doesn't break in the future

[MicheleBertoli]

Thank you very much, @santino.
Problem and fix are clear, and thanks for adding an additional test.
As always, high-quality PR which I'm more than happy to merge.