Changes to table constructor formatting severely degraded performance

[JohnnyMorganz]

In fbe55eb (#182), we changed the formatting tactic for table constructors.
Originally, to see if a table constructor is over the column width, we would check the difference between the position of the start and end brace, and add it to the current width taken. This was quite naiive, because if you had a badly formatted table constructor with lots of spaces, it would go over the width.

To change this, we first attempt to format the whole table on a single line. If it then goes over width, then we stop, scrap the formatting we did, and then format on multiple lines. For code with lots of (nested) tables, this degraded performance significantly, as we double the amount of (quite expensive) work done per table, which adds up exponentially as you increase the depth of a table.

Reverting to a snapshot before this commit heavily improves performance, therefore a new heuristic needs to be defined for this.
We could either revert to the tactic we had originally (which still isnt great), or we could find something else.
Maybe, rather than attempting to format the whole table singleline then check if its over width, we format a small chunk at a time, examine how far we are, and bail early. This short circuiting should reduce the amount of operations done significantly.