Some Basic Refactorings

## Change 0/4: Refactor switch statements in BlockCarpentersSlope
The first change replaces the switch statement with polymorphism for the slope types. A new abstract class SlopeType is created and the extending classes are made according to the values for the enumerated type "Type" in the Slope class.  The original enumerated type, but an attribute of type SlopeType is added.  The SlopeType class has a static method to instantiate on of its subtypes depending on the Slope.Type value.  This is replaced with a factory pattern in the second change.
 
## Change 1/4: Create new abstract class SlopeType with child classes
The methods onHammerLeftClick and onHammerRightClick on BlockCarpentersSlope utilize a switch statement to change the current slopeID of the block depending on the type of the slope.  It is difficult to read, and both methods would need to be changed if a new slope type is added later on.  Methods can be added to the abstract class later on to replace more of the switch statements.
The reason the Slope.Type type attribute is left is because it is used elsewhere in the system. The new SlopeType reference is instantiated in the Slope's constructor based on the Slope.Type value using a static function from the SlopeType abstract class using a switch case.

## Change 2/4: Eliminate Arrow Anti-Pattern from BlockCoverable.java 
The BlockCoverable class has a huge amount of arrow anti-pattern which hinders the overall readability of the code. These anti-patterns also make the code error-prone, whereas a developer charged with maintaining the source code might end up adding mistakes due to lack of proper code structure.

The impact of eliminating the arrow anti-patterns using guard clauses is strictly positive as it improves the maintainability and readability of the code without affecting any functionality.

## Change 3/4: Refactor BlockCoverable.java class by applying Extract Method
 A redundant code smell of the BlockCoverable class is sequential conditional statements sharing the same returns value. Moreover, the same conditional statement sequences can be found throughout the code. This duplicated code is bad style and classifies as a code smell. 

In order to remove this smell, we extracted the repeated code and extracted it to a private method. We then replaced all of the instances of the duplicated code by the newly created method. Ultimately, this improves the total maintainability by encapsulating identical functionality in one place.

The impact on the system is purely positive, as these changes do not affect the functionality of the class. Moreover, maintenance operations on the codebase will be less prone to introduce errors in the system since duplicated behaviour has been removed.