Force built-in methods to demand the needed return type

Consider the following ops:
```java
@Plugin(type = Op.class, priority = LOW)
OrangeEaterOp implements FunctionOp { ... }

@Plugin(type = Op.class, priority = HIGH)
AppleEaterOp implements FunctionOp { ... }
```

These currently would have following built-in methods in the `FruitNamespace`:
```java
AppleCore eat(Apple a) {
return (Apple) match(a).apply(a)
}

OrangePeel eat(Orange o) {
return (Orange) match(o).apply(o)
}
```

Now suppose we have a hybrid type:
```java
Orple implements Apple, Orange { ... }
```

And we run the following code:
```java
OrangePeel peel = ops.fruit().eat((Orange) myOrple);
```

It will match the wrong op, and thus then cast the result to the wrong return type.

This is a danger with how the type-safe namespace signatures are currently set up. We made the decision to allow the ops matcher some flexibility in which op gets matched. However, they do not constrain the return type to match that expected, nor even test it before casting. Fortunately, the Ops matcher _can_ constrain the return type, so let's do that!

Start with the FruitNamespace built-in methods and the Ops matcher described in the issue, focusing on how the expected return type is handled during matching and casting. Reproduce the Apple/Orange hybrid case with Orple, then confirm that matching rejects an operation whose return type does not satisfy the requested namespace method.

Written by the indexing model from the issue text.