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.
You refer to readability in terms of _recognizable language idioms_. I'm talking about readability as in _the code should read like a sentence_. Those are different, albeit complementary, ways to look at it. Which one feels more _natural_ to a reader is, in my opinion, subjective.

I agree that this kind of code is _very stable_ and not worth centralizing for the sake of removing duplication. The real value for me is the human readability as in "reading like a phrase".
In this case _structural honesty_ is of secondary importance, since the purpose is to be closer to natural language. Where it retains its value is at the conditional.

Having said that, I have no intention to promote this change in the code base. I added is as a matter of personal preference but I don't consider it to be essential, so I'm going to remove it and use the conditional instead if that's preferable.