Prevent panic arising from too many fetch threads

[gterzian]

You can currently reliably crash servo by simply doing a lot of fetches from a script(and I mean "a lot", as in thousands):

pid:2606 Thread spawning failed: Os { code: 35, kind: WouldBlock, message: "Resource temporarily unavailable" } (thread ResourceManager, at libcore/result.rs:1009)
 0:43.28 pid:2606 stack backtrace:
 0:43.28 pid:2606    0:        0x110b37c5e - __ZN9backtrace9backtrace5trace17hcbb011583cfd3d3aE
 0:43.28 pid:2606    1:        0x110b3896c - __ZN72_$LT$backtrace..capture..Backtrace$u20$as$u20$core..default..Default$GT$7default17h29fd18b15ff4d63eE
 0:43.28 pid:2606    2:        0x110b389ed - __ZN9backtrace7capture9Backtrace3new17h2273fa824674c020E
 0:43.28 pid:2606    3:        0x10e6c8c22 - __ZN5servo4main28_$u7b$$u7b$closure$u7d$$u7d$17h522942b550442ad3E
 0:43.28 pid:2606    4:        0x1115c7978 - __ZN3std9panicking20rust_panic_with_hook17h14490a1041ee4235E
 0:43.28 pid:2606    5:        0x1115c748c - __ZN3std9panicking18continue_panic_fmt17h7beddad0ba45f4eaE
 0:43.28 pid:2606    6:        0x1115c7378 - _rust_begin_unwind
 0:43.28 pid:2606    7:        0x1115e4ce1 - __ZN4core9panicking9panic_fmt17hc2d37e7312d32a42E
 0:43.28 pid:2606    8:        0x10fee1a1d - __ZN4core6result13unwrap_failed17haa5916ca2e33f98fE
 0:43.28 pid:2606    9:        0x10ffa09fb - __ZN3net15resource_thread19CoreResourceManager5fetch17h7d351f3ad26ffa44E
 0:43.28 pid:2606   10:        0x10ff9c8df - __ZN3net15resource_thread22ResourceChannelManager11process_msg17hd3fc5ada0efe4314E
 0:43.28 pid:2606   11:        0x10ff99d1d - __ZN3net15resource_thread22ResourceChannelManager5start17hdcdccbba842efa93E
 0:43.28 pid:2606   12:        0x10fed022f - __ZN14profile_traits3mem12ProfilerChan25run_with_memory_reporting17h3946f04f898c5663E
 0:43.28 pid:2606   13:        0x10fe5af82 - __ZN3std10sys_common9backtrace28__rust_begin_short_backtrace17h68cacde7212439bdE
 0:43.28 pid:2606   14:        0x10febbc34 - __ZN3std9panicking3try7do_call17hf8548275900b72c3E.llvm.4645138343911158568
 0:43.28 pid:2606   15:        0x1115d3eee - ___rust_maybe_catch_panic
 0:43.29 pid:2606   16:        0x10ff85bc2 - __ZN50_$LT$F$u20$as$u20$alloc..boxed..FnBox$LT$A$GT$$GT$8call_box17had60d95554992805E
 0:43.29 pid:2606   17:        0x1115ab07b - __ZN3std3sys4unix6thread6Thread3new12thread_start17hba53abd905cebc29E
 0:43.29 pid:2606   18:     0x7fff6ee11304 - __pthread_body
 0:43.29 pid:2606   19:     0x7fff6ee1426e - __pthread_start
 0:43.29 pid:2606 [2019-01-27T12:11:08Z ERROR servo] Thread spawning failed: Os { code: 35, kind: WouldBlock, message: "Resource temporarily unavailable" }
 0:43.32 pid:2606 called `Result::unwrap()` on an `Err` value: Io(Custom { kind: NotFound, error: StringError("Bogus destination port.") }) (thread ScriptThread PipelineId { namespace_id: PipelineNamespaceId(1), index: PipelineIndex(1) }, at libcore/result.rs:1009)

The cause appears to be the fact that CoreResourceManager currently spawns one thread per fetch.

The simple fix seems to be using a threadpool.

Note that these threads are mostly waiting for the network response to be done, either at wait_for_response, or wait_for_cached_response