Remove Reload4J dependency from core module

### User Story

As a user deploying an app that interacts with Sleeper, I don't want Sleeper dependencies to include specific logging dependencies other than the SLF4J API, so that I can choose my own logging library.

### Description / Background

SLF4J is designed to allow you to choose your own logging engine. It expects a library to only include the SLF4J API as a dependency, and then any logging engine can be included and integrated in a deployment artefact.

See the SLF4J documentation for libraries:

https://www.slf4j.org/manual.html#libraries

> **BASIC RULE: Embedded components such as libraries or frameworks should not declare a dependency on any SLF4J binding/provider but only depend on slf4j-api.** When a library declares a transitive dependency on a specific binding, that binding is imposed on the end-user negating the purpose of SLF4J. Note that declaring a non-transitive dependency on a binding, for example for testing, does not affect the end-user.

Currently Sleeper includes Maven dependencies in the core module that integrate SLF4J with Reload4J.

We'd like to avoid unnecessary logging dependencies that will then be forced on consumers of Sleeper libraries unless they specifically exclude them.

### Acceptance Criteria

**Given** I add the Sleeper clients module as a dependency of my application
**When** I use SLF4J in my project and choose a different logging engine than Sleeper
**Then** the logging engine I chose will be used, and Reload4J will not be included

### Technical Notes / Implementation Details

We'll need to consider where we should declare our logging dependencies, and how to use them consistently in the project.

In order to retain logging in scripts and the admin client, we may need to split up our clients module. We'd need one module that will be used by the scripts, which would have logging included, and another module to be used as a library, which would not.

Our clients module also includes Hadoop dependencies which use Log4J. It may be worth reviewing whether this is necessary and raising further issues.