Allow for more flexible control of connection backlog and number of connections accepted "at once"

[ghost]

This PR proposes a form for increased flexibility in a) controlling the backlog size for the listening connection(s) a Tornado application ends up using, and b) controlling how many connections are accepted during one iteration of Tornado's I/O loop, something that currently is inherently tied to the default backlog size (hence both changes with a single commit).

Tornado applications can admittedly already effectively control the backlog size applied to their listening socket(s). They may do so through ~~a) importing and altering the value of the _DEFAULT_BACKLOG module variable from netutil~~ (can't do so because default function arguments are assigned during function creation, not invocation), or b) resorting to initializing their listening sockets differently than what the example in the user guide illustrates, e.g. invoking bind oneself.

The second option has two drawbacks. First, it necessitates changing the "simple" application initialization code to a more involved one just to be able to specify own backlog. Second, by changing the code thus, the application will have to resolve and bind each socket itself -- something Tornado otherwise would have done for it "for free" with its very useful bind_sockets. Of course bind_sockets is also part of the API, and may be called as well, but that turns the code into an even more involved variant for initialization.

~~The first option does not have the aforementioned drawbacks, of course -- the application can be initialized as per the "simple" example in the user guide, having set the imported _DEFAULT_BACKLOG to a value application prefers by default.~~

More importantly, however, both options make it impossible to have Tornado not specify any backlog argument to listen at all. These proposed changes partially aim at alleviating that limitation. Thing is, a future version of Python is free to change how the "default reasonable value" is chosen for listen, and Tornado, being a framework of increasing adoption, in an increasingly varied number of scenarios, may do well by allowing applications to defer to said default behaviour by Python, instead of insisting on a "magic" number of its own.

So this PR proposes to first and foremost change the default backlog size to None, allowing Tornado to be able to correspondingly omit providing backlog argument to listen and thus defer to a backlog as decided by Python. Of course, specifying an integer value means the value will be passed to listen, as before.

Additionally, due to the default backlog size now potentially being None, the number of connections attempted accepted at one time can no longer simply follow the default backlog size as before. We use this opportunity to add an additional module variable which may be used to control the number [of connections to try and accept], deferring (if None) to default backlog size if the latter is non-zero, or ultimately, 128 (a final fallback for lack of a better magic value).

There is a prior conversation touching on this topic.