Mechanism to deprecate/rename/remove configuration properties

### User Story

As a developer of Sleeper, I want tools to rename or remove configuration properties, so that when this is necessary I can easily avoid impacting users.

### Description / Background

If instance/table properties are renamed, the old name should still work.

If properties need to be removed, they should be first documented as deprecated, with an explanation of why and
recommendations for how to proceed. Deprecated properties should be retained for a significant period. When a property is removed, the system should continue to behave as the user would expect. Nothing should fail because a property has been removed. Ideally the property should still be recognised so the user can be informed of what happened.

We'd like mechanisms to manage these changes to configuration properties.

### Technical Notes / Implementation Details

We can add the ability to give aliases for instance and table properties, so that when we change a property name we can add its old name as an alias in the property definition. If a value is set for that alias it should be read as a value for that property. We could split out a separate issue for this.

We can add a marker for deprecation that we can set on a property definition. We'd need to work out how to display this in the different places we show properties. We'd need to be aware that the reasons and process for deprecation will need to be documented in the property description as well. If the property is no longer actually applied, that should be explained in the property description. If there's a value set for a deprecated property, we could notify the user during CDK deployment or when editing properties, and include the property description.

When a property is removed, it might be simpler to leave deprecation as the only mechanism to keep the user aware of what is happening. If there's a value set for a property that is no longer recognised, we could notify the user during CDK deployment or when editing properties, and explain that the property may have been removed.

An alternative for a removed property would be to leave the property with a flag that it's not just deprecated, but no longer used at all. Again, we could notify the user during CDK deployment or when editing properties.