update production: Make sector production a bit more predictable

update production: Make sector production a bit more predictable

Sector production computes a number of intermediate values, and rounds
many of them.  We've tinkered with the rounding a few times.  It
currently works as follows.

There are two production efficiencies, both shown by the production
command: sector p.e. (column eff) governs how efficiently work is
converted to units of production, and p.e. (column p.e.)  governs how
much product each unit of production yields.

Production is limited by available work, materials and resource
contents.  These limits are all rounded down.

Example: if a unit takes 16 work (tech or guns), then 600 work at 100%
sector p.e. can make at most 37 units, rounded down from 600 * 100% /
16 = 37.5.  76 work at 76% sector p.e. can make 3, rounded down from
76 * 76% / 16 = 3.61.

Output is units times p.e.  Level output isn't rounded.  Item output
is rounded down.

Example: a tech center making 37 units at p.e. 0.6 (edu=20) yields 37
* 0.6 = 22.2 tech (before tech log).  3 units yield 1.8 tech.

Example: a defense plant making 37 units at p.e. 0.6 (tech 35) yields
22 guns (rounded down from 22.2).  3 units yield 1.8g, randomly
rounded.

If item output needs to be adjusted downward (production backlog), the
number of units made is likewise adjusted.  It is rounded randomly.

Example: a 100% refinery with 156 work can make 156 units.  Its
p.e. at tech 30 is 5.0, so this yields 780p.  But if it already has
9500p, it can make only 499 more.  That's 99.8 units, rounded randomly
to either 99 or 100.

Materials and money consumed are a multiple of units made.  No
rounding there.

Resource depletion depends on units made and is rounded randomly.

Work consumed is units made times work per unit divided by sector
production efficiency.  Rounded randomly.  Any work left can normally
be used at the next update (it "rolls over").

Example: the tech center making 37 units consumes 37 * 16 / 100% = 592
work, with 8 work left.  It also consumes 37d 185o 370l $11100.

Example: the tech center making 3 units consumes 3 * 16 / 76% = 63.2
work, randomly rounded to 63 or 64, with 13 or 12 work left.  It also
consumes 3d 15o 30l $900.

Example: the defense plant making 3 units consumes work the same.  It
additionally consumes 1o 15l 30h $30 when it makes one gun, and twice
as much when it makes two.

Rounding intermediate values like "units of production" is awkward.
It's better to round only final results.  These are item output,
materials consumed, resource depletion and work consumed.  Round item
output down, and the rest randomly.  Don't round level output (it's a
floating-point value) and money consumed (also floating-point, since
the previous commit).

For item production, this shifts the random variations from number of
products made to materials and work consumed.

Example: the first defense plant again makes 22 guns (now rounded down
from 22.5).  The second one now always makes two guns (rounded down
from 3.61 * 0.6 = 2.166) instead of 1.8 randomly rounded.

This is nice, because budget and production can now predict the number
of items made exactly.  Before, budget fluctuated randomly just like
the update, and production rounded down.

Note that budget used to be even worse: until commit 6f7c93c
(v4.3.31), we rounded units of production randomly rather than down.
The 100% tech center randomly made 37 or 38 units, which is much more
relevant than random rounding of item output.

Furthermore, work is now fully used both for item and level
production, to the limit permitted by materials and resource contents.

Example: the first tech center now makes 37.5 units, yielding 37.5 *
0.6 = 22.5 tech.  It consumes 37.5d 187.5o 375l $11250 and all 600
work (fractions randomly rounded).

Example: the second tech center now makes 3.61 units yielding 1.805
tech, consuming 3.61d 18.05o 36.1l $1083 and all 76 work.

The production command duplicates much of the update's sector
production code, so it needs a matching update.  The next commit will
reduce the duplication.

Signed-off-by: Markus Armbruster <armbru@pond.sub.org>