[Patterns] problematic re-use of ProblemIDs

The ProblemIDs `IncompatibleTypesInConditionalOperator` and `IncompatibleTypesInEqualityOperator` have some "interesting" history.

### `IncompatibleTypesInConditionalOperator`

Right from the beginning this ID was used for two different situations:
* `ConditionalExpression`, see `ProblemReporter.conditionalArgumentsIncompatibleTypes(ConditionalExpression, TypeBinding, TypeBinding)`
* this might be obsolete in 1.8, see #3089
* `InstanceOfExpression`, see `ProblemReporter.notCompatibleTypesError()` which originally expected an `InstanceOfExpression` and has later seen re-use for other situations, too.

### `IncompatibleTypesInEqualityOperator`

* originally issued via `notCompatibleTypesError(EqualExpression, TypeBinding, TypeBinding)`
* this method is being merged into `notCompatibleTypesError(ASTNode, TypeBinding, TypeBinding)` (as of #3069)

This new method is being shared from the following locations, and internally selects the ProblemID from the ast location:
* `InstanceOfExpression`
* `Pattern`
* `EqualExpression`

**Question1:**
Are toplevel patterns (i.e., not members of a RecordPattern) correctly classified during error reporting?

### ID vs message

I can see that the messages issued by the compiler are ok-ish, but I wonder if it is a good idea to share IDs from ancient Java versions for new error situations. Notably: is the current classification sufficient for JDT/UI for proposing suitable quickfixes (if any)?