Improve inferrability of JuMP functions

[blegat]

As the MOI backend does not have a concrete type, Julia is not able to infer the result of the MOI.get calls. This PR adds type asserts to help inferrability and adds tests to unsure that the functions are now inferrable.

Closes #1824

[mlubin]

There's a subtle difference in regular type assertions and return value type assertions:

julia> f() = 1
f (generic function with 1 method)

julia> function g()
           return f()::Float64
       end
g (generic function with 1 method)

julia> function h()::Float64
           return f()
       end
h (generic function with 1 method)

julia> g()
ERROR: TypeError: in g, in typeassert, expected Float64, got Int64
Stacktrace:
 [1] g() at ./REPL[2]:2
 [2] top-level scope at none:0

julia> h()
1.0

Which should we prefer?

Also we should distinguish the cases where MOI defines or should define an expected return type like SolverName and NumberOfVariables (jump-dev/MathOptInterface.jl#31) and the cases where we're asserting beyond what MOI implies because JuMP assumes Float64.

[odow]

Also we should distinguish the cases where MOI defines or should define an expected return type like SolverName and NumberOfVariables (JuliaOpt/MathOptInterface.jl#31) and the cases where we're asserting beyond what MOI implies because JuMP assumes Float64.

Use a type assertion when MOI defines what type is returned.

function objective_sense(model::Model)
    return MOI.get(model, MOI.ObjectiveSense())::MOI.OptimizationSense
end

Use a return type assertion for JuMP-specific values.

function objective_value(model::Model)::Float64
    return MOI.get(model, MOI.ObjectiveValue())
end

[blegat]

I agree with @odow suggestion. Some solvers might return a Float32 instead of a Float64 and it's better to do the conversion in JuMP rather than forcing the solver wrappers to do these corrections.

[blegat]

I have move type asserts to return value type assertion when appropriate

[mlubin]

Larger architectural question: which functions are we guaranteeing are type stable and which are we not, and how do we document this?

[mlubin]

What if a solver returns an Int32?

[blegat]

We should use a conversion here, that is also consistent with num_constraint in #1850

[blegat]

Larger architectural question: which functions are we guaranteeing are type stable and which are we not, and how do we document this?

I think that by default all jump function should be type stable (or with a Union with Nothing) and we should explictly document it when it's not the case