Use safelist(s), allowlist(s) where applicable

[JuanitoFatas]

Sorry I dont know why my fork disappear, reopened this PR from #158.

This Pull Request updates:

• terminology in the codebase
• rake task changed to rake generate_safelists

Safelist, allowlist is easier to understand and less offensive.

Original motivation: rails/rails/issues/33677, other community efforts examples:

• [ci skip] change all instances of blacklist and whitelist to denylist… rails/rails#33681
• deserialize_jsonapi not found on controller graphiti-api/graphiti#10
• Finish converting whitelist and blacklist references rails/rails#33718
• Use friendlier terminology in YAML.safe_load ruby/psych#378
• Use friendlier terminology in rubysocket.h ruby/ruby#2008
• Use friendlier terminology in _leaf_helpers.erb ruby/ruby#2009
• Use permitted in line_length.rb rubocop/rubocop#6464
• Update friendlier terminology in Gem::SafeYAML rubygems/rubygems#2463
• Update terminologies dtao/safe_yaml#93
• Introduce Request::ALLOWED_SCHEMES and deprecate existing constant rack/rack#1314
• Update terminology in http_status.rb rubocop/rubocop#6466
• Update terminology in rails/validation.rb rubocop/rubocop#6467
• Update terminology in BUILD_DETAIL.md rspec/rspec-core#2576
• Update terminology in BUILD_DETAIL.md rspec/rspec-expectations#1083
• Update terminology in BUILD_DETAIL.md rspec/rspec-mocks#1246
• Update terminology in BUILD_DETAIL.md rspec/rspec-support#356
• Use clearer terminologies pry/pry#1874
• Update terminology in test description from completion spec pry/pry#1875

[flavorjones]

Thanks for resubmitting! Planning to spend time on OSS later this week.

[flavorjones]

Hi! I've got some time this weekend and would like to get this into the next version of Loofah, v2.3.0.

I'll be pushing some changes on top of your branch to ensure that we can deprecate these names in two stages:

1. deprecate them, but don't break any users who are directly referencing the old names (e.g., provide aliases for constants and placeholder files)
2. remove them, which shouldn't happen in a patch version and instead will be a second set of commits for 2.4.0 or maybe 3.0.0.

and this PR would be the first stage. So the commits I'll add will provide backwards-compatibility for now.

[flavorjones]

Sorry - now I see you've done this already! I double-checked that the old tests pass with the new code, and that was green, so I'm going to merge this, and it'll be in v2.3.0.

Apologies it took so long to circle back to this.

[flavorjones]

Merged manually

[flavorjones]

v2.3.0 has been released.