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.
> 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.

OK, that's a good counter-argument, but I think we're in a bit of *damned-if-you-do-damned-if-you-don't* scenario.

The *reason* that you see the above exception is that *by default*, `Fixture` has no `ISpecimenBuilder` that can handle `42`. However, you could add one, in which case you wouldn't see that error any longer.

Thus, the argument hinges on a particular configuration of `Fixture`, and not on the internal workings on `FreezeOnMatchCustomization`. However, I admit that `new FreezeOnMatchCustomization(42)` would probably lead to some weird behaviour.

Based on this, I'm inclined to keep it as is. However, I was wondering if we'd then be missing out on some opportunities, like:

```C#
new FreezeOnMatchCustomization(somePropertyInfo);
new FreezeOnMatchCustomization(someParameterInfo);
new FreezeOnMatchCustomization(someFieldInfo);
// etc.
```

I admit that I haven't thought this through, so perhaps it's completely nonsense after all?