Potentially breaking: Make null validation errors consistent across schema

[jquense]

Previously, schema that parse to invalid values like InvalidDate or NaN always tripped the typeError validation before the nullability error. This was the due to typeError no longer firing on null values, with the expectation that it would always hit the newer nullability check.

This change fixes the issue for Number and Date schema, so that they act the same as String and other schema, where null values do not trigger the typeError validation. The consequence of this is that casting null values for non-nullable number schema, now return null instead of NaN and dates, return null instead of InvalidDate. Essentially these schema will not fruitlessly attempt to coerce null into a number or date anymore.

I am marking this as a bug fix since it is, and as with most bug fixes, could also be considered a breaking change. I'm going to optimistically not cut a v2 for this. If you have unexpected changes it is likely due to number/date schema hitting different validation errors (nullability).

Previously for these schema it was common practice to change the typeError for these schema to something like "this is required"assuming the issue was due to invalid nulls. NOW the schema will show the locale.notNull message, so if you may want to adjust that to something more user friendly if you surface default locale messages to users (we don't generally recommend that).

[jquense]

fixes @jarnaiz issue in #1952