Add start_value, lower_bound, and upper_bound support for GenericAffExpr

[odow]

Closes #3550

This PR is up for debate, but our problem is that some usages of @variable return expressions of variables, and then common operations like lower_bound or set_start_value do not work.

In most common cases we can make this work, so we probably should. This would improve the user-experience, particularly for those using Complex number support.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (35e7713) 98.26% compared to head (4e256ef) 98.19%.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #3551      +/-   ##
==========================================
- Coverage   98.26%   98.19%   -0.07%     
==========================================
  Files          37       37              
  Lines        5580     5599      +19     
==========================================
+ Hits         5483     5498      +15     
- Misses         97      101       +4     

Files	Coverage Δ
src/aff_expr.jl	97.54% <100.00%> (+0.19%)	⬆️

... and 4 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[odow]

Hmm. There are actually a bunch of edge cases once you dig in:

    model = Model()
    @variable(model, x)
    y = (1 - 2im) * x
    @test !has_lower_bound(y)
    set_lower_bound(y, 1 + 2im)

What is lower_bound(x)? Maybe we should only support expressions that have +/-1 or +/-im as coefficients.

[mlubin]

My sense is that this might cause more confusion than it solves. Next we'll have a request to support lower_bound and upper_bound for nonlinear expressions, which is not trivial to implement.

[blegat]

Setting bounds should only be allowed with one term and real coefficient. If complex, the user can be explicit by doing set_lower_bound(imag(aff), ...)

[odow]

My sense is that this might cause more confusion than it solves.

Yeah. But it's currently causing confusion because some outputs from @variable are actually AffExpr, and even something like real(x) is not a variable but an AffExpr.

Setting bounds should only be allowed with one term and real coefficient

This is reasonable.

[mlubin]

Setting bounds should only be allowed with one term and real coefficient

That's a fair compromise.

[odow]

How about this now

[odow]

Removed the method. How's the now