Freeze on match customization

Addresses #120 by introducing a new customization that freezes specimens based on a set of criteria.

### Usage

The `FreezeOnMatchCustomization` uses the `IRequestSpecification` abstraction as a way to match the incoming requests with the frozen specimen. For example:

```csharp
var fixture = new Fixture();
var freeze = new FreezeOnMatchCustomization(
    typeof(string),
    new PropertySpecification(typeof(string), "Foo"));
fixture.Customize(freeze);
```

This will assign the same string value to _all properties of type `string` named `"Foo"`_.

Multiple matching criteria can also be combined using the `OrRequestSpecification`. Here's an example:

```csharp
var fixture = new Fixture();
var freeze = new FreezeOnMatchCustomization(
    typeof(string),
    new OrRequestSpecification(
        new PropertySpecification(typeof(string), "Foo")
        new ParameterSpecification(typeof(string), "bar"))); 
fixture.Customize(freeze);
```

When no matching criteria are specified, the `FreezeOnMatchCustomization` behaves like the current `FreezingCustomization`, that is it will only match by _exact type_. More concretely:

```csharp
var freeze = new FreezeOnMatchCustomization(typeof(string));
```

is the same as saying:

```csharp
var freeze = new FreezeOnMatchCustomization(typeof(string), new ExactTypeSpecification(typeof(string));
```

### Follow-ups

The are a few things I deliberately left out until after I gather your feedback:

- Since the `FreezeOnMatchCustomization` effectively supersedes the existing `FreezingCustomization`, I propose we obsolete it and rename the `FreezeOnMatchCustomization` to simply be `FreezeCustomization` for consistency.
- I'll add the XML documentation once the feature is finalized.

I look forward to your comments.
True. We could pass the object accepted through the constructor _as-is_ to the `Resolve` method. However, that can potentially lead to some unexpected results.

Let's say we change the constructor to accept the target as `object`. That would allow me to say:

```csharp
var freeze = new FreezeOnMatchCustomization(42);
fixture.Customize(freeze);
```

Given the signature of the constructor, it's not completely unreasonable to expect to be able to pass a literal and _have it be treated as the frozen value_. What happens instead is that AutoFixture will throw an exception when it's time to resolve a request:

> Ploeh.AutoFixture.ObjectCreationException: Ploeh.AutoFixture.ObjectCreationException : AutoFixture was unable to create an instance from 42, most likely because it has no public constructor, is an abstract or non-public type.

IMO, this behavior breaks the expection set by the liberal constructor.

Now, we could do a quick check on the `target` object and resolve its `Type` when appropriate:

```csharp
var request = target is Type ? target : target.GetType();
context.Resolve(request);
```

So the value being passed as `target` gets ignored _unless_ it happens to be a `Type`. Again, I don't think this is the behavior the caller would expect.

At this point we could invoke the _garbage in, garbage out_ rule and simply resolve the target _as-is_.

Alternatively, we could mitigate the chances of failure by doing the right thing based on what the `target` is. For example, if it's a `Type` then we resolve it, otherwise we freeze the specified object. This is definitely doable but it comes at the cost of increased complexity.

There's another aspect to this discussion. The same kind of problem applies to the `matcher` parameter too, since it's being presented as a rather generic `IRequestSpecification`. In fact, right now nothing prevents me from doing this:

```csharp
var freeze = new FreezeOnMatchCustomization(
    typeof(int),
    new AnyTypeSpecification());
fixture.Customize(freeze);
```

which, of course, leaves me with nothing but a broken fixture.

I believe there's a difference between the two parameters, though; while the `matcher` _has to_ be open since it can be any kind of criteria (or a combination of them), the only freezing target that actually makes sense for the customization (at least in its current implementation) is a `Type`.

In conclusion, we can take one of two routes as I see it:

1. Limit the `target` to be a `Type` as that's what leads to the "_pit of success_".
2. Accept any `target` and extend the customization's behavior to freeze specific objects in addition to types.

Am I missing something?