Limit number of parts of a key - #286

* Limit number of parts of a key

tomli has quadratic time complexity when handling parts of a key
(via Flags.is_ calls in key_value_rule's loop, and maybe elsewhere).
This isn't a problem unless a document has an excessive number (10_000-ish)
of parts in a key. Limiting input seems like the best fix here.

`sys.getrecursionlimit` and `RecursionError` is already (and in the non-mypyc
version, implicitly) used for `MAX_INLINE_NESTING`.
Keys aren't parsed recursively, but that's an implementation detail;
`RecursionError` works nicely for names recursive structures.

(cherry picked from commit e1fdb94)

Recently there have been a few TOML implementations that have added a
nesting limit depth to prevent using up huge amount of CPU/memory with a
document like "a.«10,000 more» = 1". For example:

hukkin/tomli#286
python-poetry/tomlkit#468
BurntSushi/toml@2e90ced6

There's probably more. In a casual quick look, many implementations
already have such a limit and if they don't, they probably should.

I added a comment in the toml-test README for it, but I think mentioning
it in the spec would also be useful. If only to set a recommended lower
limit like we do for 64bit ints. This is helpful both for implementation
authors (as a reminder they should add such a limit) and users (as a
reminder there may be a limit).

For example BurntSushi/toml has never had such a limit until recently,
even though I've always known this sort of thing is a problem. I ...
just never thought of it. This would have been fixed years ago if there
had been a comment in the spec. That's probably the same for tomli.

Recently there have been a few TOML implementations that have added a
nesting limit depth to prevent using up huge amount of CPU/memory with a
document like "a.«10,000 more» = 1". For example:

hukkin/tomli#286
python-poetry/tomlkit#468
BurntSushi/toml@2e90ced6

There's probably more. In a casual quick look, many implementations
already have such a limit and if they don't, they probably should.

I added a comment in the toml-test README for it, but I think mentioning
it in the spec would also be useful. If only to set a recommended lower
limit like we do for 64bit ints. This is helpful both for implementation
authors (as a reminder they should add such a limit) and users (as a
reminder there may be a limit).

For example BurntSushi/toml has never had such a limit until recently,
even though I've always known this sort of thing is a problem. I ...
just never thought of it. This would have been fixed years ago if there
had been a comment in the spec. That's probably the same for tomli.