Created Unassigned: ValidatorOptions.PropertyNameResolver interferes with ValidatorTester [7178]

I had a suite of Web.Api tests (including both FluentValidation tests and [integration tests](http://www.strathweb.com/2012/06/asp-net-web-api-integration-testing-with-in-memory-hosting/)) that seemingly started to fail half way through the test run. Looking more closely revealed that the FluentValidation tests only started failing consistently after the integration tests ran. I finally found the culprit: in the integration tests, I was setting a custom property name resolver via `ValidatorOptions.PropertyNameResolver`. All subsequent FluentValidation tests that either used `ShouldHaveValidationErrorFor` or explicitly looked at `ValidationFailure.PropertyName` failed. The latter is potentially reasonable (it's a way to test that your PropertyNameResolver is working), but the former really seems to defeat the purpose of `ShouldHaveValidationErrorsFor`.

The culprit for the `ShouldHaveValidationErrorsFor` failures is [this comparison in ValidatorTester](https://github.com/JeremySkinner/FluentValidation/blob/master/src/FluentValidation/TestHelper/ValidatorTester.cs#L37):

```csharp
var count = validator.Validate(instanceToValidate).Errors.Count(x => x.PropertyName == accessor.Member.Name);
```

So... I resolved both of my problems by setting `ValidatorOptions.PropertyNameResolver` to null in the test's setup. But, that sort of defeats the purpose of `ShouldHaveValidationErrorsFor` and only solves the problem if you remember to null it out.

While investigating this further, I discovered an even greater oddity:

* If `ValidatorOptions.PropertyNameResolver` is set _after_ a validator's `RuleFor` is defined, `ShouldHaveValidationErrorsFor` behaves as expected.
* If `ValidatorOptions.PropertyNameResolver` is set _before_ a validator's `RuleFor` is defined, `ShouldHaveValidationErrorsFor` fails because the aforementioned line in ValidatorTester.cs is given the property-name-resolved `x.PropertyName` rather than the actual property name.

This phenomenon is demonstrated in the attached test class's `ShouldHaveValidationErrorFor_fails_if_PropertyNameResolver_set_before_rule` test and [here](https://github.com/NGPVAN/FluentValidation/blob/test-helper-validator-options-issue/src/FluentValidation.Tests/ValidatorOptionsTestProblem.cs#L35). If everything was working as expected, this test should fail.

One could theoretically correct this problem by setting `ValidatorOptions.PropertyNameResolver` to null in the constructor of `ValidatorTester`, or change the aforementioned string comparison to use either the direct comparison or the result of passing `accessor.Member.Name` through the resolver. But both seem a bit... dirty.

Any ideas?