Semantically invalid RFC2822 is accepted, implying the library meets those requirements

From the RFC2822 itself:

A date-time specification MUST be semantically valid. That is, the
day-of-the-week (if included) MUST be the day implied by the date,
the numeric day-of-month MUST be between 1 and the number of days
allowed for the specified month (in the specified year), the
time-of-day MUST be in the range 00:00:00 through 23:59:60 (the
number of seconds allowing for a leap second; see [STD12]), and the
zone MUST be within the range -9959 through +9959.

https://tools.ietf.org/html/rfc2822

Yet, I can add jibberish day-of-week values, like changing the test file from "Tue" to "Zue", or simply a mismatched day.

Also, equally non-sensical input values such as February 31st appear to pass through the dayjs constructor when using the RFC2822 format without any issues.

I would expect the library would throw invalid input errors, much like if I input "dog" as my date string.

Minimal code sample can be seen below:

```javascript
const dayjs = require('dayjs')

const time = 'Zue, 31 Feb 2019 09:46:50 GMT+1'
const actual = '2019-03-03T08:46:50.000Z'
const d = dayjs(time)

console.log(d.toISOString())
console.log(d.valueOf())


// properly throws error
const d1 = dayjs('dog')
d1.toISOString()
```

Start by locating the RFC2822 parsing path invoked by dayjs(time) and reproduce the sample with the invalid weekday and February 31st. Add regression coverage for semantically invalid weekday, date, time, and zone values, then verify these inputs are rejected without changing valid RFC2822 parsing.

Written by the indexing model from the issue text.