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.
Actually, I don't think it's *that* subjective. In fact, I believe it hurts readability. Here are some reasons - some of them measurable:

First of all, the following code is a well-known C# idiom:

```C#
if (foo == null)
    throw new ArgumentNullException("foo");
```

Whenever I see code like that, it's almost like it isn't there. It basically looks like that in all well-written code bases, so that expression has an extremely small cognitive overhead. Everyone immediately knows what it does.

It's portable to boot: you can take that expression from one code base, and drop it into another code base, and it's just going to work as is. In other words: it has no coupling.

It's also [extremely unlikely to change](http://blog.ploeh.dk/2014/08/07/why-dry).

Furthermore, if you use Kevlin Henney's method of [replacing none-whitespace with Xs](http://vimeo.com/97329157), you'll get this:

```C#
XX XXXX XX XXXXX
    XXXXX XXX XXXXXXXXXXXXXXXXXXXXXXXXXXXXX
```

which is still *structurally honest* code.

On the other hand, if you X out

```C#
Require.IsNotNull(foo, "foo");
```

you get:

```C#
XXXXXXXXXXXXXXXXXXXXXX XXXXXXX
```

which is more difficult to recognise as a branching expression.

As far as I can tell, such an expression adds cognitive overhead, and thereby makes the code (marginally) harder to read.