Inlined Fixture into its own graph.

This is done only for performance reasons - there are no functional
difference.

FWIW, this seems to have improved performance by about 20 %. However, this
is based on a not particularly rigorous measurement:
I ran the entire test suite defined by AutoFixture.sln before and after
this change on my Lenovo X1 Carbon laptop (Intel Core i5, 8 GB RAM).

Before:
========== Total Tests: 2965 passed, 0 failed, 0 skipped, took 14,40 seconds ==========
========== Total Tests: 2965 passed, 0 failed, 0 skipped, took 14,06 seconds ==========
========== Total Tests: 2965 passed, 0 failed, 0 skipped, took 13,77 seconds ==========
========== Total Tests: 2965 passed, 0 failed, 0 skipped, took 14,94 seconds ==========
========== Total Tests: 2965 passed, 0 failed, 0 skipped, took 13,76 seconds ==========

After
========== Total Tests: 2965 passed, 0 failed, 0 skipped, took 11,49 seconds ==========
========== Total Tests: 2965 passed, 0 failed, 0 skipped, took 11,86 seconds ==========
========== Total Tests: 2965 passed, 0 failed, 0 skipped, took 11,30 seconds ==========
========== Total Tests: 2965 passed, 0 failed, 0 skipped, took 11,17 seconds ==========
========== Total Tests: 2965 passed, 0 failed, 0 skipped, took 10,96 seconds ==========
Refactored IsTarget to a slightly faster impl.

The problem with IsTarget was that it searched through the graph to find
the target every time it was invoked, and since this predicate was invoked
recursively, this took a long time because it caused loop within loops.

The new implementation is more complicated, but the private
TargetSpecification class holds the target directly, which means that it's
only necessary to find the target once, every time the predicate must be
used in a call to ReplaceNodes or SelectNodes.

The same not particularly rigorous tests as described in the last commit
indicates a 6 % performance improvement.

Before:
========== Total Tests: 2965 passed, 0 failed, 0 skipped, took 10,11 seconds ==========
========== Total Tests: 2965 passed, 0 failed, 0 skipped, took 10,29 seconds ==========
========== Total Tests: 2965 passed, 0 failed, 0 skipped, took 10,08 seconds ==========
========== Total Tests: 2965 passed, 0 failed, 0 skipped, took 10,22 seconds ==========
========== Total Tests: 2965 passed, 0 failed, 0 skipped, took 09,92 seconds ==========

After:
========== Total Tests: 2965 passed, 0 failed, 0 skipped, took 9,34 seconds ==========
========== Total Tests: 2965 passed, 0 failed, 0 skipped, took 9,51 seconds ==========
========== Total Tests: 2965 passed, 0 failed, 0 skipped, took 9,58 seconds ==========
========== Total Tests: 2965 passed, 0 failed, 0 skipped, took 9,56 seconds ==========
========== Total Tests: 2965 passed, 0 failed, 0 skipped, took 9,35 seconds ==========
Changed two calls of Single() to First().

While I think that Single() is more correct, because it will implicitly
check the assertion that there's only a single matching item, it's
theoretically slower because it MUST traverse the entire sequence, whereas
First() stops at the first match it finds.
I can't measure much of a performance difference, but since the TargetMemo
property from the previous commit already already took the plunge and
replaced Single() with First(), I think it makes sense to do this
consistently, as it may provide a performance improvement in scenarios
where users have larger sets of customizations.
Incremented patch version,

to indicate performance tuning.