In response to a report from Domas that we are seeing HTMLCacheUpdate::invalidate...

In response to a report from Domas that we are seeing HTMLCacheUpdate::invalidate() queries that touch hundreds of thousands of rows and cause significant slave lag:
* Check the number of rows to be updated before actually doing the query, and if it is too large, repartition the job. Due to caching and job queue lag, it is possible that the original partitioning could be pathologically inaccurate.
* Respect $wgRowsPerQuery (regression due to r47317) but increase the default from 10 to 100. It was originally chosen with a low value because I imagined that it would help reduce slave lag, but this is not generally the case since the queries may be in the same transaction.
* Fix lack of initialisation of $jobs in insertJobs() (sloppy but not a bug)
* To avoid queueing up jobs unnecessarily and to reduce the chance of jobs being repartitioned a large number of times as links are incrementally added, make the size threshold for queueing double the job size instead of equal to the job size
* Add a check of title array size to the immediate case, to avoid updating hundreds of thousands of rows when an incorrect size is stored to memcached.