Properly ignore Date tests with bad dynamic input

### Introduction

This is the correct fix for #1353 and not a complete reversion, as in #1414.

Feature detection is used to determine whether a browser has an implementation of `(new Date()).toString()` that correctly matches the date formatting required by the test.

For more details on this issue, please also reference the following link:

http://tech.bluesmoon.info/2008/09/date-inconsistencies-in-javascript.html

### Explanation

This explanation is also available in the comments of the related tests for future reference.

Certain tests are ignored on browsers where `(new Date()).toString()` has a format that's incorrectly suited for the provided format string.

The reason why these tests need to use `(new Date()).toString()` is due to the fact that this code tests timezone parsing in `Y.Date.parse`, and we need to make sure that this code will pass regardless of what timezone we run these tests in.

In all other browsers, `(new Date()).toString()` outputs the following:

```
Sun Oct 27 2013 11:24:18 PDT-8000
a   b   d  Y    H  M  S  z
```

This is the target format that we want to test, which is correct. Since we need it to work across timezones, we can't hard code this string, and we need to provide a specific Date in UTC time, requiring the use of `Date.UTC()`.

However, in IE, `(new Date()).toString()` outputs the following:

```
Sun Oct 27 11:24:18 PDT 2013
a   b   d  Y  H  M  S   z
```

Because the format of the string is incorrect, the test will fail, which is the correct behavior.

Therefore, we have two options:

1. Make sure this test works across every browser, but only in one timezone.
2. Make sure this test works on most browsers, but in every timezone.

As a result, we decided to make the test work in most browsers, but be ignored in IE, so that developers across the world can still develop on YUI successfully.

Although this test would fail in IE, this does not change the correctness of the code - a string in the correct format of `%a %b %d %Y %T GMT%z` will be parsed  correctly regardless.   

### Conclusion

Reverting all of the work done in the following commits:

- https://github.com/yui/yui3/commit/02edfa676095eb9c78516eb24ac90d8f5ec7a3cb

- https://github.com/yui/yui3/commit/0dff07d29e478901b873a6654515a12cd6746fdd

- https://github.com/yui/yui3/commit/cf663b78e79444abfb8605d786c57f0f2bbdb521

Is the incorrect solution in resolving the failing tests.  

The work done in these commits is also relevant to the other Intl work being done on the team, and should be a part of this release.  The correct resolution to the failing tests is the one available inside of this PR, which is to split up the timezone-specific tests and ignore them if the dynamic input (`Date.toString()`) does not provide the date format that we are attempting to test.