Significantly decrease parser file size by compacting parser table

### Summary

**This pull request nearly halves the gzipped size of generated parsers.**

### Problem

The largest part of a Jison-generated parser is its `table`: a large array containing objects with numeric keys and (arrays of) numeric values.

Two kinds of patterns occur frequently in such a table:

1. **repeated long numerical arrays**
<br>_example:_ `tables = [{ 5: [1,3,4,6,7,8,15], 6: 7}, { 20: [1,3,4,6,7,8,15], 9: 8 }]`
2. **objects where all keys have the same value**
<br>_example:_ `tables = [{ 5: [200,204], 17: [200,204], 20: [200,204], 21: [200,204] }]`

### Solution

I tackled the first case by [storing frequently occurring arrays into **temporary variables**](https://github.com/RubenVerborgh/jison/commit/a7bca896ed54e563b1fc9c1af72f9abf370b1de7):
```
var a = [1,3,4,6,7,8,15],
    tables = [{ 5: a, 6: 7 }, { 20: a, 9: 8 }];
```

I tackled the second case by [creating such objects with an **auxiliary function `o`**](https://github.com/RubenVerborgh/jison/commit/8d64d352783b213188f64be712de70919117c5e1):
```
var tables = [o([200,204], [5, 17, 20, 21])];
```
That also leads to new long arrays with numbers, which can be optimized under the first case.

Not only does this lead to a significantly **decreased filesize** of the parser, it also leads to **less memory usage**, as it avoids having multiple copies of the same array in memory.

To support such chunks of reusable code, the `generateModule_` function has been [updated](https://github.com/RubenVerborgh/jison/commit/1171af582d98a3e96f03ffc7334590318170e948) to return an object with `commonCode` and `moduleCode` (instead of only `moduleCode`).

### Results

A parser I am working on benefited significantly from the new table generation function:

- **before:** **173kb** _(generated)_, **155kb** _(minified)_, **36kb** _(gzipped)_
- **optimization 1:** **138kb** _(generated)_, **112kb** _(minified)_, **36kb** _(gzipped)_
- **optimizations 1 and 2:** **91kb** _(generated)_, **71kb** _(minified)_, **19kb** _(gzipped)_

The decrease from 36kb to 19kb is a **47% reduction**.
New parsers can initialize this to 0 indeed, but it is not necessary. If they do, variable names can be shorter (as they don't have to be unique across all parsers, only within a single parser). However, minification will reassign variable names anyway, making them as short as possible.

Summarizing: if you want, you can make `createVariable` a member function with `nextVariableId` as a member variable, so names will be shorter in unminified versions.