[krperry]

Fixes three guide dot problems in simple tables, checked against
Braille Formats 2016, section 11. There is one commit per fix, and
each commit has its own regression tests in
SimpleTableGuideDotsTest. The tests format real BBX documents to
BRF and check the table lines.

1. Single guide dots (9b05ad4)

Problem: In Example 11-3, a single guide dot followed "bore" and
"began" in the Past column. Formats 11.6.1.f calls for two or more.

Cause: PageBuilder.fillSpace filled whatever cells were left
after the entry, minus one blank on each side. A three-cell gap
therefore got one dot. Its minimum argument is never used.

Fix: fillSpace takes an optional minimumFillers (default 1, so
existing callers are unchanged). The simple table formatter passes
MIN_GUIDE_DOTS = 2 for non-empty entries. When only one dot fits,
nothing is drawn and column positions stay the same. Blank-entry fills
and the TOC are unchanged.

Tests: Example 11-3, plus a table whose entries leave room for 0,
1, 2 and 3 dots.

2. Guide dots on multiline entries (9606905)

Problem: In Sample 11-4, "20 ac/ territory" and "1 ac/ territory"
wrap, but guide dots were drawn after "20 ac/" and "1 ac/".

Cause: addRow added guide dots to every column but the last. For
columns after the first, it placed them on the entry's first line,
whether or not the entry ran over. Formats 11.6.1.g says not to use
guide dots after a column runover other than the first column.

Fix: After placing an entry, addRow checks whether the formatted
entry ended on a later line than it started. If so, it skips guide
dots for that entry. Row heading runovers still get guide dots after
their last line (11.5.2.b).

Tests: Sample 11-4 (both entries, with "Variable" keeping its
dots). A single-line entry with dots in a 17-cell column. The same
entry with no dots once a 10-cell column makes it wrap.

3. Unnecessary guide dots and column sizing (56913ac)

Problem: In the weather table, every High Temp. and Low Temp.
entry had a stray guide dot, and "East Village" took three lines.

Cause: calculateColumnWidths shrinks short columns and then
hands the leftover cells, one at a time, to every column whose content
is still longer than the starting width. A column's content includes
its column heading. Each temperature column took a cell because its
heading is 10–11 cells long, though its entries are 7 cells and the
heading wraps anyway. That spare cell is where the stray dot went. The
first column, whose entries really do run over, got only one extra
cell.

Fix: Leftover space now goes first to columns whose entries (not
column headings) are longer than the column, then to the other
columns as before. The column widths change from 9/9/9/5 to 11/8/8/5.
The temperatures have no guide dots, "East Village" and "Woodland
Hills" take two lines, and "Highland Park" fits on one line. The
change has no effect on tables with no leftover space or no runover
entries. Example 11-3 and Sample 11-4 come out the same as before this
commit.

Tests: The test checks the whole weather table layout.

Testing

• mvnw package (full reactor with tests): BUILD SUCCESS. utd ran
  702 tests and brailleblaster-core ran its default suite, both with
  0 failures. The core suite includes the 6 new tests.
• Each new test was run against the code before its fix: every
  regression test failed there, except the eligible single-line entry
  check, which guards against over-suppression and passes both before
  and after.
• Tests were run locally on Windows only.

Notes

• The three .bbx fixtures come from the reported .bbz files.
• I could read the Formats section 11 rules (11.5.2.b, 11.6.1.f and
  11.6.1.g), but not the braille images for Example 11-3 and Sample
  11-4. The expected output in the tests is BrailleBlaster's corrected
  output, checked against those rules, not compared cell by cell with
  the printed samples.
• Not changed here: in Sample 11-4, "Williamson's" is split with the
  continuation indicator (,williamson" / 's) because the column is
  too narrow for the runover.