Uniform handling of location and URIs

Many Log4j components use URI-sh configuration attributes:

- configuration factories allow a [`ConfigurationSource`](https://logging.apache.org/log4j/2.x/javadoc/log4j-core/org/apache/logging/log4j/core/config/ConfigurationSource) to be specified as URI, URL or file name,
- the [`MutableThreadContextMapFilter`](https://logging.apache.org/log4j/2.x/javadoc/log4j-core/org/apache/logging/log4j/core/filter/MutableThreadContextMapFilter) accepts an URI or file name to retrieve its configuration,
- JSON Template Layout accepts an URI to retrieve its configuration.

Each of these configuration attributes is handled in a different way. For example:

- JTL only handles `file:` and `classpath:` URIs,
- the way URIs without a schema are interpreted differs.

We should introduce an abstraction similar to [`ResourceLoader`](https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/core/io/ResourceLoader.html) that:

- supports at least the `classpath`, `file`, `http` and `https` protocols,
- is extensible to new protocol handlers,
- specifies how a relative URI without a protocol needs to be interpreted. This mechanism should be extensible: e.g. a standard implementation could interpret it as `classpath` or `file` resources. A `log4j-web` specific implementation could interpret it as `war`, `classpath` or `file` resource,
- has a coherent way to handle errors: file names and Java URLs don't always follow the URI syntax.

**Remark**: other Log4j components might also profit from this abstraction. For example the `File` appender could be easily adapted to use network filesystem URIs or at least it should be able to use NIO file systems.