FiniteStateMachine.process: Refuse Non-Deterministic Finite State Machines

Previously, a (more or less) random path was chosen in case of ambiguity
in FiniteStateMachine.process. Instead, we now raise a NotImplementedError.
FiniteStateMachine.process: raise NotImplementedError when epsilon-transition is reached.

Further code cleanup
Small correction.
trac #16504: A mandatory 'nonnegative' argument for MixedIntegerLinearProgram.new_variable() until the standard changes
trac #16504: Tastes and colors ................
trac #16504: Broken doctest
trac #16504: additional doctest for nonnegative=False
Cosmetic changes
first attempt inspired from gurobi_backend
trac #16504: Updates the tutorial
16497 : fix the integer case for gurobi and cplex
fixing #10128: vector_space_dimension() should return infinity when it is
16497 : add doctest
Trac #16497: Rounding problem with CBC and gurobi LP solvers

Running `make ptestlong` with CBC package installed leads to the
following doctest errors:

{{{
File "src/doc/en/thematic_tutorials/linear_programming.rst", line 442,
in doc.en.thematic_tutorials.linear_programming
Failed example:
    p.solve()
Expected:
    2.0
Got:
    1.0
}}}

{{{
File "src/sage/graphs/graph.py", line 3215, in
sage.graphs.graph.Graph.minimum_outdegree_orientation
Failed example:
    max(o.out_degree()) == ceil((4*3)/(3+4))
Expected:
    True
Got:
    False
}}}

{{{
File "src/sage/numerical/optimize.py", line 777, in
sage.numerical.optimize.binpacking
Failed example:
    all([ (v in b1 or v in b2 or v in b3) for v in values ])
Expected:
    True
Got:
    False
}}}

The problem seems to come from `get_variable_value` method in the CBC
backend that does not round its result when the variable is binary.
Actually, the same problems exists for integer variables in both gurobi
and CBC backends (at least), but no doctest detects it.

URL: http://trac.sagemath.org/16497
Reported by: tmonteil
Ticket author(s): Thierry Monteil
Reviewer(s): Nathann Cohen
Trac #16504: A mandatory 'nonnegative' argument for MixedIntegerLinearProgram.new_variable() until the standard changes

This should create an unbounded real variable:
{{{
sage: p = MixedIntegerLinearProgram()
sage: x = p.new_variable(nonnegative=False)
}}}

We should see `nonnegative` as a toggle, not as a type. The following
should also work as expected intuitively:
{{{
sage: x = p.new_variable(integer=True, nonnegative=False)
sage: x = p.new_variable(integer=True, nonnegative=True)
}}}

URL: http://trac.sagemath.org/16504
Reported by: jdemeyer
Ticket author(s): Nathann Cohen
Reviewer(s): Jeroen Demeyer
Trac #16539: FiniteStateMachine.process: Refuse Non-Deterministic Finite State Machines

Previously, a (more or less) random path was chosen in case of ambiguity
in {{{FiniteStateMachine.process}}}. Instead, we now raise a
{{{NotImplementedError}}}.

Ideally, process would follow all possible paths. This is #16538, but
will need some more time.

As a stop-gap measure, we at least raise a {{{NotImplementedError}}} if
the situation occurs.

URL: http://trac.sagemath.org/16539
Reported by: cheuberg
Ticket author(s): Clemens Heuberger
Reviewer(s): Daniel Krenn
Trac #10128: Ideal.vector_space_dimension() should return Infinity for non-zero dimensional ideals.

Right now, we throw a {{{TypeError}}} which definitely wrong, since the
type is correct.

URL: http://trac.sagemath.org/10128
Reported by: malb
Ticket author(s): Martin Albrecht
Reviewer(s): Julian Rueth
Trac #16423: Table of MOLS from the handbook and comparison with Sage

With this branch we have a `MOLS_table` function which displays what
Sage can handle, and also compare it with what the Handbook of
Combinatorial Designs (2ed) claims.

We seem to be rather far but I have several construction that somehow
make the gap smaller. But there is a lot to review already `:-P`

Nathan

URL: http://trac.sagemath.org/16423
Reported by: ncohen
Ticket author(s): Nathann Cohen
Reviewer(s): Vincent Delecroix