Bump `set_time_limit()` at the start of the update process, instead of mid-way.

[dd32]

Currently WordPress calls set_time_limit( 300 ) before it installs an update, however it calls this at the point between unzipping the files, and copying them into place.
For plugins/themes/translations/etc it's this call for core it's this one.

This, combined with the much higher core package sizes (More than doubled since 3.7) results in some people hitting the default php execution cap of 30 seconds during the download phase when testing locally (For example, 11MB @ 2.5mbit/s = 35 seconds).

To make it more 'annoying', The core_upgrader Lock is put in place before the package is downloaded, so if they run into the timeout during downloading, the lock will still be in place in wp_options for 15 minutes.

set_time_limit should be set at the start of the process, likely at the point of the locks being created, before downloads have begun.

[costdev]

Move set_time_limit() to before the lock is created, or before the package is downloaded. Also change 300 to 5 * MINUTES_IN_SECONDS for consistency elsewhere in Core.

[costdev]

@dd32 Is 46292.diff what you were thinking?