WIP - Adding custom configuration options feature

Allows any `RuntimePolicy`, `Tab`, `Inspectors`... to be provided with a custom configuration that they define themselves. This is currently available for all configuration elements that are represented by a `DiscoverableCollectionElement`.

Currently, to allow the users to add additional status codes, content types, uri's to blacklist etc.. a `PolicyDiscoverableCollectionElement` was added to allow this by defining a `ContentTypeElementCollection`, `StatusCodeElementCollection` and `RegexElementCollection` without any correlation (from a config point of view) by which component it will be used.

There is an `IConfigurable` interface defined that was introduced to allow those corresponding policies to read these additional configuration elements, and this by passing in the complete configuration section (this seems a little bit overkill as well).

The new approach allows instances of types that were discovered by means of the `DiscoverableCollectionElement` to specify additional configuration specifically linked to their "type" and indicate that they want to consume that additional configuration by implementing the `INeedMyCustomConfiguration` interface.

This PR shows (although still compatible with current config) how the `UriPolicy`, `StatusCodePolicy` and `ContentTypePolicy` were adapted to make use of this. 

![customconfig](https://f.cloud.github.com/assets/1467346/1786848/e298752a-68fb-11e3-99f8-6b765841908e.png)

As you can see the old way of setting the additional content types or status codes is still supported
But the interesting part is that the xml content after the `<add..>` is completely up to the consumer of the custom confguration to decide how it looks like. 

the `INeedMyCustomConfiguration` provides the implementer with a `CustomConfigurationProvider` to whom they can ask for the custom config. The custom config can be asked to the provider in the form of an `XmlSerializer` compatible type like

``` C#

customConfigurationProvider.GetMyCustomConfigurationAs<StatusCodePolicyStatusCodes>();

[XmlRoot(ElementName = "statusCodes")]
[XmlRoot(ElementName = "statusCodes")]
public class StatusCodePolicyStatusCodes
{
    [XmlElement(ElementName = "add")]
    public StatusCodePolicyStatusCode[] StatusCodes;
}

public class StatusCodePolicyStatusCode
{
    [XmlAttribute("statusCode")]
    public int Value { get; set; }
}
```
or in case it is not compatible, the content can be requested as a simple string and the consumer can then decide how to process it, which gives them complete flexibility (as long as when it is put in the config it is part of a valid xml document)

``` C#
customConfigurationProvider.GetMyCustomConfigurationAs<string>()
``` 

What do you guys think? /cc @avanderhoorn @nikmd23 

This might be the base to replace the `AppSettings` related config changes of #671