[Locale] Fixed the StubLocaleTest for ICU versions lower than 4.8.

Symbol for Brazilian Real is BR$ only in ICU 4.8. All previous and later versions use R$.

Links to the data files:
* http://source.icu-project.org/repos/icu/icu/tags/release-4-8/source/data/curr/en.txt
* http://source.icu-project.org/repos/icu/icu/tags/release-4-4/source/data/curr/en.txt
* http://source.icu-project.org/repos/icu/icu/tags/release-49-1/source/data/curr/en.txt
[Form] Fixed failing tests for DateTimeToStringTransformer.

Tests were only failing at the end of the month. PHP uses current day if it is not passed. Since February was used in the test cases, date was being moved to the next month (February has less days than other months).
merged branch jakzal/form-tests-fix (PR #6517)

This PR was merged into the 2.1 branch.

Commits
-------

81967f6 [Form] Fixed failing tests for DateTimeToStringTransformer.

Discussion
----------

[Form] Fixed failing tests for DateTimeToStringTransformer

Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -
License of the code: MIT
Documentation PR: -

Tests were only failing at the end of the month. Since February was used in the test cases, date was being moved to the next month (February has less days than other months).

If a day is not passed, \DateTime's constructor will set it to the first day of the month:

```php
var_dump(new \DateTime('2010-02'));

object(DateTime)#1 (3) {
  ["date"]=>
  string(19) "2010-02-01 00:00:00"
  ["timezone_type"]=>
  int(3)
  ["timezone"]=>
  string(13) "Europe/London"
}
```
\DateTime is used in the test assertions.

However, DateTimeToStringTransformer::reverseTransform() uses \DateTime::createFromFormat(), which sets a missing day to the current day:

```php
var_dump(\DateTime::createFromFormat("Y-m", '2010-02'));

object(DateTime)#1 (3) {
  ["date"]=>
  string(19) "2010-03-01 20:09:26"
  ["timezone_type"]=>
  int(3)
  ["timezone"]=>
  string(13) "Europe/London"
}
```

I changed the date in the test case to avoid failures. If we need to be sure that month's not going to be changed, I'll update my PR.
merged branch jakzal/stub-tests (PR #6515)

This PR was merged into the 2.1 branch.

Commits
-------

ef6f241 [Locale] Fixed the StubLocaleTest for ICU versions lower than 4.8.

Discussion
----------

[Locale] Fixed the StubLocaleTest for ICU versions lower than 4.8

Bug fix: no
Feature addition: no
Backwards compatibility break: no
Symfony2 tests pass: no but for other reason in an another component
Fixes the following tickets: #5517
Todo: -
License of the code: MIT
Documentation PR: -

Symbol for Brazilian Real is BR$ only in ICU 4.8. All previous and later versions use R$.

Links to the relevant data files:
* http://source.icu-project.org/repos/icu/icu/tags/release-4-8/source/data/curr/en.txt
* http://source.icu-project.org/repos/icu/icu/tags/release-4-4/source/data/curr/en.txt
* http://source.icu-project.org/repos/icu/icu/tags/release-49-1/source/data/curr/en.txt

---------------------------------------------------------------------------

by jakzal at 2012-12-29T19:23:25Z

Note that currently *USE_ICU_DATA_VERSION* is required for some tests to pass. This is inconsistent with *Locale::getIcuDataVersion()* which returns *Locale::ICU_DATA_VERSION* if *USE_ICU_DATA_VERSION* is not set. Technically intl extension shouldn't be needed to run the stub tests.

Following code could fix the issue for StubLocale tests:

```php
class StubLocaleTest extends LocaleTestCase
{
    // ...
    protected function getIntlExtensionIcuVersion()
    {
        // Locale::getIcuDataVersion(), which is used to determine the directory of stubs,
        // uses Locale::ICU_DATA_VERSION if USE_INTL_ICU_DATA_VERSION is not given
        if (!getenv('USE_INTL_ICU_DATA_VERSION')) {
            return Locale::ICU_DATA_VERSION;
        }

        return parent::getIntlExtensionIcuVersion();
    }
}
```

This code cannot be placed in the LocaleTestCase as intl tests need the icu data version from the intl extension.

I'm not sure if this is desired and therefore I didn't include it in my PR. Let me know your thoughts and wether I should create another PR for this, use the current PR or forget about it.