[5.5] Fixed date comparison validators failing when a format is specified

[pantherdd]

[ This is a follow-up to the closed PRs #20789 and #20868. ]

Fixed Validator failing on 'before_or_equal:today' when the input is today's date and a format is specified

The issue was that the time part was bleeding through from the current timestamp in DateTime::createFromFormat.

Test case:

• Validation rule: 'birth_date' => ['required', 'date_format:Y-m-d', 'before_or_equal:today']
• '2017-08-27' was parsed as '2017-08-27 22:41:37'.
• 'today' was parsed as '2017-08-27 00:00:00'.
• Validation failed.

---

Some further information I found (thanks to @arjasco 's comment on the previous PR):

• [5.4] Validation Rule: date_format bug #17642 is the issue that has re-surfaced here, and what this PR would fix for good.
• [5.4] Validation Rule: date_format bug #17642 (comment) describes the reason why developers can't use a format with a ! prepended.
• #17642 - Reset day parameter when using Y-m #20566 is just a one-off workaround for a single specific date format, and even for that format, it doesn't support 'before' and 'after' rules.

---

@taylorotwell "Isn't this going to break applications? What if people want the time part?"

If you have time fields in the date format, the validation will still use them.
http://php.net/manual/en/datetime.createfromformat.php

If format contains the character !, then portions of the generated time not provided in format, as well as values to the left-hand side of the !, will be set to corresponding values from the Unix epoch.

>>> DateTime::createFromFormat('!Y-m-d H:i:s', '2017-08-28 18:57:24')
=> DateTime {#890
     +"date": "2017-08-28 18:57:24.000000",
     +"timezone_type": 3,
     +"timezone": "Europe/Paris",
   }

I have also added a number of date validation tests in a second commit. These tests deal with the time parts, and show that the fix I made is not breaking anything.

If you still think this change might cause issues, please provide a test case that this PR causes to fail, so that I have a chance of fixing the problem.

---

[ When porting my fix to branch 5.5, I added extra test cases for the new date_equals validator to have that covered too. This exercise led me to a bug in its implementation, which I also fixed. ]

Fixed Validator failing on 'date_equals' when a format is specified

Also added a number of test cases.
The issue was that === always returns false for the two separate DateTime instances returned by getDateTimeWithOptionalFormat.

---

The fix can easily be applied to branch 5.4 too, so that users of the previous version get the benefits too. It doesn't have to be backported, as I originally wrote the fix for that branch. Here is the PR, it just needs to be merged. (It contains the first 2 commits of this PR.)