patgen SIGSEGV on aarch64-linux

[Johannes Hielscher]

> Alternatively, does increasing swap on your machine solve it?
Good hint! More swap ⇒ higher limits until patgen segfaults (run time).
Even the lame zram trick helps in lifting the limits.

Hence, given that the trie{,c}_size sum essentially conducts a test of
accessible memory at run time, this
  * explains the inconsistent results and the odd numbers which Keno
    and me found out the hard way,
  * means RAM limitations for running and compiling patgen (running
    tests),
  * enables power users with memory-laden machines to modify patgen.ch
    for virtually infinite dictionary sizes.

There are no “right” numbers for trie{,c}_size in an absolute sense (We
can't know the machines a user will run patgen on), and it's just luck
that nobody on x86_64-linux (or another “large” platform) had such
little RAM in their box to find that issue there.

Which values should be shipped with the TL sources? With plenty of zram,
both my boxes would even be happy with Keno's original
110021182/54677566.

A notice like
> If patgen is segfaulting on runtime, reduce the trie{,c}_size values,
> or (better) increase RAM or swap size of your machine.
could be added to the comments in patgen.ch, so that future
builders/users don't have to go through all this again.

Best,
Johannes