Benchmarks for actix-service: focused around UnsafeCell usage

[dunnock]

Actix-service would benefit some white box benchmarks. For instance if I would want to look at what can be done with current implementation of a Cell, it would be easier to judge is there any affordable and safe solution.

This PR is adding basic performance testing facility for alternate implementations of a service, specifically one is using UnsafeCell vs RefCell implementation. Benchmarks repeating to avoid mistake of a first run.

Specifically AndThenService benchmark (bench/and_then.rs) compares 3 implementations:

1. Current via Cell which is Rc<UnsafeCell<(A,B)>>
2. RefCell via Rc<RefCell<(A,B)>>
3. RefCell via Rc<RefCell<(A,B)>> where instead of custom baked AndThen state combinator standard Future AndThen is used (though that required to wrap future in a Box)

Results are surprising and vary depending on OS/architecture:
Mac OS X i5 2.6GHz

AndThen with UnsafeCell #2 time:   [50.931 ns 51.918 ns 53.378 ns]
AndThen with RefCell #2 time:   [51.276 ns 51.782 ns 52.348 ns]
AndThen with RefCell via future::and_then                                                                            
                        time:   [225.47 ns 228.73 ns 232.46 ns]

Ubuntu 18 Xeon E5-2660 W2

AndThen with UnsafeCell #2 time:   [44.421 ns 46.810 ns 49.167 ns]
AndThen with RefCell #2 time:   [48.391 ns 48.972 ns 49.514 ns]
AndThen with RefCell via future::and_then
                        time:   [93.348 ns 93.799 ns 94.261 ns]

It consistently shows that standard Future combinators are slower. Though RefCell seems similar or marginally slower which might be just mistake of measurement (1-2ns?).

Similar results for "primitive" cell service comparison (bench/unsafecell_vs_refcell.rs):

Service with UnsafeCell #2 time:   [27.171 ns 29.248 ns 31.067 ns]
Service with RefCell #2 time:   [28.457 ns 30.320 ns 31.935 ns]

If there are any other ideas for implementation I would like to extend these benchmarks trying those ideas.

[cetra3]

This is a great idea! I'm not surprised that the futures combinators are slower

[JohnTitor]

Looks good!