Fix regex parsing of the "data-validate" attribute

Performing user-defined pattern validation using a regular expression in the "data-validation" attribute on an <input type="text"> textbox currently only works with the simplest of regex expressions.

To see what I mean, try a very simple example:
`<input type="text" data-validate="/\w/" />`
and enter a single character from 'a' to 'z'. **This fails validation when it should pass.**

I have tried many variations and adjustments to the data-validate attribute contents (such as "/[\w]/", "/[a-zA-Z]/", etc) but to no avail.

Upon inspection of the mForm.Core.js file I see that in line 232 you are calling the following:

```javascript
return el.getAttribute('data-validate').length >= 3 && (el.getAttribute('data-validate')).test(value);
```

Running a `typeof on el.getAttribute('data-validate')` I get back 'string', when I believe you intended to get a RegExp object (the data type created when you type an escaped `/regex/` literal in JavaScript).

In order to fix this problem, I suggest you instead construct a RegExp object from the "data-validate" attribute contents (as in the attached pull request).

----

The only limitation of this approach is that it does not parse the regexp string in the same way as a JS regex literal, so any ['modifier flags'](http://www.w3schools.com/jsref/jsref_obj_regexp.asp) (such as /i /g or /m) at the end of the string will not be handled correctly using this method.

Three possible solutions exist to this problem:
1. Use the built-in regex literal parser somehow (possibly using `eval()`). Doing this in a safe manner (from a security perspective) somehow could be the most elegant solution.
2. Change the API and documentation so that the data-validate attribute does not assume regex literal syntax (such as '/' prefixes/suffixes) and instead assumes just a simple regex string. The primary issue with this is that the existing pattern templates 'email', 'min', and 'max' would conflict (so it would be impossible to validate a regex of the word "email", for example).
3. Use a more heavyweight regex literal parser to extract any modifiers manually (using string and regex methods) and pass those to the `new RegExp(string, modifiers)` constructor.

I believe my current solution solves the problem in a simple yet effective way (as long as you include documentation of the fact that modifiers are not supported), but a more complex solution (such as one of the three listed above) would also suffice.