Require unlashing of input superglobals

[JDGrimes]

This updates the validated/sanitized input sniff to also check for
slashing. This could have been made into another sniff instead,
however, it would have required lots of duplicated logic and this sniff
would need to be updated to accommodate the use of wp_unslash()
anyway.

Currently only wp_unslash() is recognized as an unlashing function,
but this can be changed in the future if needed.

The sniff currently requires that wp_unslash() be used before the
data is passed through a sanitizing function. Sanitizing first and then
wrapping that in wp_unslash() is not accepted.

The error for missing the use of wp_unslash() is independent of the
missing sanitizing function error, so an error will be given for
missing use of an unslashing function whether or not a sanitizing
function is used, and vice versa.

Unslashing is not required when sanitization is provided via casting,
or when certain sanitization functions are used which implicitly or
explicitly perform an unslash or for which unslashing isn’t necessary.
absint() implicitly unslashes, and sanitize_key() will remove
slashes explicitly. And unslashing isn’t necessary when testing a value
with is_array(). This list can be expanded in the future, and is
configurable via the customUnslashingSanitizingFunctions property.

See #172

[GaryJones]

I don't see any $_POST or $_GET values being assigned with explicitly slashes values / values that would become slashed, and checked in tests? Not necessarily to unit test the functionality of wp_unslash() but to integration test with different data for our existing tests.

[JDGrimes]

@GaryJones I'm not sure I follow. There are some places where wp_unslash() is not used, to test that the error is given, if that's what you mean.

[GaryJones]

Nevermind - think I'm confusing myself.