Evaluate BNGL parameter expressions instead of dropping them

A parameters block may give a parameter a value that is an expression over
other parameters, such as kon koff/(Kd*NA*V). That is ordinary BNGL rather
than an edge case. Across 303 models drawn from the BioNetGen collections,
1934 of 9323 parameter declarations are expression-valued.

Until now get_parameter_value raised NotImplementedError for those, and
get_free_parameter_ids_with_values dropped them without saying anything, so
a PEtab problem built from a BNGL model quietly lost parameters.

Resolving them needs no BNG2.pl and no reaction network, because a
parameters block is arithmetic over other parameters. This adds a parser and
evaluator for that arithmetic and points BnglModel at it.

The arithmetic follows BNGL rather than Python, and the two differ in ways
that give a wrong number rather than an error. Each rule was checked against
BNG2.pl 2.9.3 by running the expression through writeNET with
evaluate_expressions turned on, which is the only export path that prints
numbers instead of copying the source text back out. Three cases catch
people out:

  -2^2       is 4, because unary minus binds tighter than the power operator
  2^3^2      is 64, because the power operator groups from the left
  rint(2.5)  is 3, because rint is floor(x + 0.5)

Resolution is partial, so one unusable definition costs that parameter and
whatever depends on it rather than the whole block. Anything left out is
named in a warning instead of disappearing.

The table of expressions and their expected values is checked from both
sides. It is pinned in the tests so it runs without BioNetGen installed, and
a second test rebuilds the same values from a real BNG2.pl when one is on
the path.

Author: wshlavacek