Implementation of DateTime, additional Regex methods and more

Hi Zach,

As the title says, I implemented almost complete versions of DateTime and TimeSpan with working unit tests.

I also cleaned up a bit my previous implementation of Enumerators for imperative collections (ResizeArray, Dictionary, MatchCollection...), added more expression replacements to the Regex module and exposed a couple of things which I need for the HTML extensions: Async.protectedCont and WebRequest.Url. I hope this is fine. 

I added a line to CommonOperators.fs to fix issue #111 too.

Please have a look when you have time and tell me what you think.

Cheers!
Alfonso
Thank you very much for adding this additional functionality into FunScript and adding tests around it. Unfortunately, these tests are a little bit fragile (especially on the slow TeamCity CodeBetter build server).

The `check` test function compiles the quotation in .NET and JavaScript (using FunScript) and compares the results to see if they are the same. This means the code is actually executed twice and using `DateTime.Now` or `DateTime.UtcNow` in any test is likely to result in something unreliable.

An additional issue here is that `DateTime.Now` will use the culture specified for the current thread to get the time in the correct timezone. I'm not sure if JInt takes this into account when resolving the time in the JavaScript that gets executed.

Some of these tests are currently failing on the build server. It would be nice if we were able to keep them all, as it is great to have the coverage and ensure that we don't break anything here in the future. We may need to be a bit cunning to make the tests more reliable though.

E.g., Here we may have a problem if the test executes in .NET before the hour boundary and JavaScript after the hour boundary say at 10:59 and 11:01 respectively.  We may also have an issue if the culture is not used to determine the local time when executing the JavaScript using JInt.

I guess ideally we'd be able to inject the time but we cannot do that (to my knowledge anyway). Instead maybe we can be a little more lenient here in the result we expect. What do you think @alfonsogarciacaro?