Add parameter to Test-IsBannedWord to skip inbound normalization

[ryannewington]

suggestion....
you have Test-IsBannedWord which normalizes and it gives an unexpected result, IMHO

for example:
"activedirectory" is in the Banned Words list

[1] Test-IsBannedWord "activedirectory" returns TRUE (expected)
[2] Test-IsBannedWord "activedirect0ry" returns TRUE (expected)
[3] Test-IsBannedWord "@ctivedirectory" returns FALSE (not expected)

with the last one it took some time to understand and I think the issue is due to the normalization rules where numbers and symbols at the beginning and end are stripped

Suggestion:
Test-IsBannedWord --> no normalization and just to test is a word in its form is in the banned word list
Test-IsBannedPassword --> supporting the actual password and the password after normalization rules

still does not solve the issue that I would be able to use @ctivedirectory as a password. The only thing I can think of is to test both the actual password and the stripped version after using normalization rules. Would require additional processing

Originally posted by @zjorz in #22 (comment)