Usability tweaks

[jpastuszek]

This PR brings some smaller changes to usability of the library. I can prepare more specialised PR if only selected features are going to be merged.

• added life time to SearchSpace - this allows user to use ptr-& types for Action and State without need for PhantomData or HKT support at cost of having to put <'a> in the impl and expand signatures
• using Fn(&Self::State) -> bool predicate instead of SearchGoal - this make it to look&feel more like Iterator API; eliminate need for Observer impl for random tree test but you need to use tiny closure instead of blanket impl
• removed Visited struct as in current state having it does not bring any benefits
• added two more benchmarks that use in memory binary tree representation and allow comparison of search performance when Action and State are passed by value or by reference

Here are benchmarks against current master branch:

master: test dfs ... bench: 13,254,952 ns/iter (+/- 5,345,397)

this: test dfs ... bench: 13,822,033 ns/iter (+/- 4,594,586) test dfs_by_ref ... bench: 23,668,700 ns/iter (+/- 3,307,109) test dfs_by_val ... bench: 24,426,540 ns/iter (+/- 3,749,642)

master (no visited): test dfs ... bench: 2,135,067 ns/iter (+/- 583,600)

this (no visited): test dfs ... bench: 2,101,213 ns/iter (+/- 877,112) test dfs_by_ref ... bench: 6,596,894 ns/iter (+/- 1,538,473) test dfs_by_val ... bench: 7,047,675 ns/iter (+/- 1,221,296)

The speed of the main test is the same as before. Results show that accessing tree in memory is significantly slower than just generating it on the fly. Tests show that passing State and Action by reference when you have your tree is already stored in memory is tiny bit faster compared to by value, presumably by eliminating clone on the data and due to smaller ptr-& size than (Action, State) tuple.

I have also investigated use of Borrow, Deref to eliminate double references with the predicate and expand functions when using ptr-& types for State but found it impossible to do without introducing another associated type representing non-ptr-& type of State - it resulted in exactly same performance; did LLVM reduced this to same code?

[jpastuszek]

Ups, forgot to rebase/squash... I will create another PR if we want this.

[aldanor]

Hey, thanks, a lot of stuff to read through, but I prob won't be able to get through it till the weekend most def(because of the web summit and all...)