Mechanism for backwards compatiblity of properties

### User Story

As a user of Sleeper, I want to be able utilise both newer and older properties names within the application
To ensure ongoing backwards compatability.

### Description / Background

Property definitions are present can be subject to change for various improvements
(e.g. to better align names with other similar properties)
However we need to continue to maintain the ability to use the properties with their given names from previous iterations under a commitment to continue backwards compatability.

A new mechanism is need to relate any changed property definitions back to the older one to allow use of both newer variants and older variants of the properties.
### Acceptance Criteria

Gherkin format example:

Given I have a new definition for a given property,
When the property is used over the older variant
Then it should still allow Sleeper to action it correctly.

### Technical Notes / Implementation Details

One such area for this improvement is the present properties for logging:

(Main sleeper level)
sleeper.logging.level

(Subsequent more specialised logs)
sleeper.logging.apache.level
sleeper.logging.parquet.level
sleeper.logging.aws.level
sleeper.logging.rootl.level

Desired to swap last two elements of the specialised ones to better align with the main property.
eg. **sleeper.logging.level.apache**

### Dependencies / Blockers

Communication of this feature to user of the application is desirable so that they are informed for future reference.

Start by locating the property definitions and logging configuration for sleeper.logging.level and the specialised logging properties. Determine how renamed properties can be related, then verify that both old and new names trigger the same behaviour; update the user-facing communication described in the issue when the compatibility mechanism is complete.

Written by the indexing model from the issue text.