Warn or error on every operation mixing Interval and number

[Kolaru]

During triage call we discussed this would be good to avoid possible pitfall.

For example when differentiating using an interval in another package, we have

d/dx (3^x) = ln(3) * 3^x  # Trusting Luca on that

Here ln(3) is no longer correctly rounded, and the guarantee is lost.

Together we would profit from having a mechanism to either disable the warning or turn it into an error.

[OlivierHnt]

Note that on master we get

ForwardDiff.derivative(x -> 3^x, interval(1))
ERROR: promotion of types Int64 and Interval{Float64} failed to change any arguments

since we have disallowed automatic conversion between Number and Interval. So this is good news at least.

One annoying aspect of such warnings is that im*y yields a warning. One option could be to make a special method for Complex{Bool} that does not throw... But that feels inconsistent.

All in all, this is a matter of where we want to draw the "safety line". The most drastic decision would be to completely disallow mixing of Interval and Number for arithmetic operations. This would be in agreement with the intended removal boolean functions for Interval which are also defined for Number.
Yet, in this scenario im*y would error.
Perhaps this is not so much of an issue if #237 is done since in that case we would define our own ComplexInterval type.