HashcodeVisitor and EqualsChecker do not take the declaring type into account

The current [`HashcodeVisitor`](https://github.com/INRIA/spoon/blob/3a8d04df7cb0319896ae98b08986a7006b208fa6/src/main/java/spoon/support/visitor/HashcodeVisitor.java) implementation does not take the [Declaring Type](https://github.com/INRIA/spoon/blob/3a8d04df7cb0319896ae98b08986a7006b208fa6/src/main/java/spoon/reflect/declaration/CtTypeMember.java#L24) of a [`CtTypeMember`](https://github.com/INRIA/spoon/blob/3a8d04df7cb0319896ae98b08986a7006b208fa6/src/main/java/spoon/reflect/declaration/CtTypeMember.java) into account. This leads to unexpected behaviour when using `HashSet`s containing `CtElement`s. Overriding the `scanCtTypeMember` in `HashcodeVisitor` and `EqualsChecker` would solve that problem.

## Example

Two `CtFieldImpl` instances representing two Java fields with **the same name** but **declared in different classes** are equal and generate the same hash code:

```java
public class Person {

private String name;

}

public class City {

private String name;

}

CtClass personCtClass = ...;
CtClass cityClass = ...;

CtField personNameField = personCtClass .getField("name");
CtField cityNameField = cityClass.getField("name");

personNameField.equals(cityNameField) // true
personNameField.hashCode() == cityNameField .hashCode() // true

```