Upgrade aws-lambda-java-log4j2 to 1.5.0 to upgrade log4j2 to 2.17.0

[PoeppingT]

This commit bumps us up so all transitive dependencies use log4j2 2.17.0 to address the DOS vulnerability in 2.16.0.

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license

[brtrvn]

I don't see log4j-slf4j-impl in the changes? We may be able to remove that dependency and trust aws-lambda-java-log4j2 to pull it in.

[PoeppingT]

This new commit standardizes log4j-slf4j-impl, log4j-core, and log4j-api across the whole project and allows log4j-slf4j-impl to bring in its own expected version of the slf4j-api. The current issue with log4j-core and log4j-api is that we have two dependent packages across the project that rely on log4j-core and log4j-api: log4j-slf4j-impl and aws-lambda-java-log4j2. The effect of this PR is to:

1. standardize the versions of log4j-slf4j-impl and aws-lambda-java-log4j2 across the project.
2. standardize the versions of log4j-core and log4j-api across the project (independent of the two above)
   This means that any upgrades to either log4j-slf4j-impl or aws-lambda-java-log4j2 should be taken in tandem, assuming that not only are the dependent required log4j-core and log4j-api versions are the same between those two versions but that those packages are upgraded as well.

The essence of this is represented in my added comment to the parent maven pom:

<!-- aws-lambda-java-log4j2 and log4j versions should be upgraded in tandem -->

In the future, if necessary, we can experiment with different versions of slf4j-api. At the moment it's assumed to be unlikely that feature upgrades to that library will be of particular use.

[brtrvn]

Do we need to explicitly include log4j-core? Shouldn't log4j-slf4j-impl pull in log4j-core as a transient dependency as needed?
Also, note that until recently, aws-lambda-java-log4j2 has not been updated as frequently as SLF4J or Log4J.