use the second day of each month to find the month name

Here's a fix for part of part 3 for #989, which concerns test failures in other time zones, and is likely the most important issue I found there. It's two characters, but it requires some explanation, though. First, here's the test:

```
export TZ=America/Asuncion
grunt nodeunit
```

Which throws out a ton of errors. That's because Paraguay has daylight savings on inconvenient dates. There are a bunch of DST issues from #989 that are really just test artifacts, but these aren't an example of it; this is a real bug in Moment.

Because October 1, 2000 isn't a valid date, month parsing breaks completely for that whole month. E.g. October 12, 2013 is a perfectly valid date, but `moment("October 12, 2013", "MMMM DD, YYYY")` returns **August** 12, 2013 (or whatever this month it is right now). The culprit is this code from `Language.monthParse()`:

```js
            for (i = 0; i < 12; i++) {
                // make the regex if we don't have it already
                if (!this._monthsParse[i]) {
                    mom = moment([2000, i]);
                    regex = '^' + this.months(mom, '') + '|^' + this.monthsShort(mom, '');
                    this._monthsParse[i] = new RegExp(regex.replace('.', ''), 'i');
                }
                // test the regex
                if (this._monthsParse[i].test(monthName)) {
                    return i;
                }
            }
```

...which is building the list of regexes to be used with the "MMM" and "MMMM" parsing tokens. But because `moment([2000, 3])` returns September 31, that code pulls out word "September" instead of "October", and thus `/^October|^Oct/` never gets added to the array of regexes. So "october" can't be recognized as part of an input string.

The logic for why Moment does this at all is that for some languages like Dutch, the month abbreviations used in *formatting* is really a function, and to spare the language from exposing a list of months *and* a function for providing that month, the code for building the *parser* just calls that function with a made up date in the right month. So an alternate fix here is to force languages that have a `monthsShort()` callback to separately provide a simple array of months.

In practice, it seems to work to just use `moment([2000, i, 2])`, so I did that. All the tests pass in America/Asuncion, and it didn't seem to negatively affect any other zones.

This also fixes many of the tests for Asia/Damascus, which has the same issue with April 1. That DST also causes other test failures not covered by this fix, but AFAIK, those are just tests assuming that April 1 is a valid date and in April, like `moment([2011, 3]).format("MMMM") == "April"`.