More permissive email regex to be closer to the standard

[gfarrell]

See Wikipedia. The allowed characters in the local-part of email addresses is a large set:

The local-part of the email address may use any of these ASCII characters:

• Uppercase and lowercase Latin letters (A–Z, a–z)
• Digits 0 to 9
• Specified special characters: !#$%&'*+-/=?^_`{|}~
• Character . (dot, period, full stop), provided that it is not the first or last character, and provided also that it does not appear consecutively (e.g. John..Doe@example.com is not allowed).
• Space and "(),:;<>@[] characters are allowed with restrictions (they are only allowed inside a quoted string, as described in the paragraph below, and in addition, a backslash or double-quote must be preceded by a backslash).
• Comments are allowed with parentheses at either end of the local part; e.g. john.smith(comment)@example.com and (comment)john.smith@example.com are both equivalent to john.smith@example.com.

There's no really sane way to match email addresses except with /^(.+)@(.+)$/, so that's what this PR does (NB: even whitespace is allowed).

Closes #60

[NinjaBanjo]

I would argue this has to at least look for a TLD as you're not going to be resolving dns without one for any valid email today.

to calrify: the .com .net .astronaut <-- being the TLD

[gfarrell]

But if you look at the spec, a TLD isn't required. Could be an IP address. Furthermore, given the possibility of using comments, any regex you write will basically be either monstrous or too restrictive.

[gfarrell]

@rhys-vdw any comments on this?

[rhys-vdw]

you're not going to be resolving dns without one for any valid email today.

While that's true, checkit actually prevented people from signing up to one of my apps when the new longer TLDs came out.

@gfarrell I agree. No reason to restrict the email unnecessarily.