Clarify which classes in core are internal vs exported

While the Log4j 2 community is committed to preserving binary compatibility for the Log4j API jar, the Log4j Core jar was intended as "private" and subject to change. It turned out that in order to extend Log4j with custom plugins, users often found it necessary or very convenient to depend on classes in the Log4j Core jar. The need to preserve binary compatibility for the Log4j Core jar made it difficult for the Log4j Core module to evolve.

This epic intends to create clarity as to which packages can be safely depended on. Existing classes in Log4j Core that should be considered private and cannot be depended on need to be moved to new packages with "internal" in the name. Such packages will not be exported when Log4j Core becomes a full-fledged Java 9 module.