add convenience method for time.Time conversion

[nitram509]

This PR replaces one aspect of the #17 PR.

When converting time.Time objects, a "new Date" object in JS is created.
This is very convenient.

For testing only, this PR will introduce the https://github.com/corbym/gocrest library.
The library enables writing more readable code (clean code) by applying the hamcrest matcher style

[norunners]

Hello, thanks again for putting this together.

This change has sparked a couple ideas I want to brainstorm.
First, we need a "generic" way for users to define their own mapping logic for specific types. I've come across many similar reflection libraries which have enabled this feature. This can be done later but want to get the idea out there. That said, I do like the idea of supporting time.Time natively but with the following requirements. We shouldn't be losing any precession if possible for the default implementation. I think it be worth preserving precision lower than seconds, again if possible. Lastly, each feature of vert.ValueOf must be complimented by the inverse logic in vert.Value.AssignTo. For example: if a Go value of type time.Time can become a js.Value via vert.ValueOf, then vert.Value.AssignTo must be able to identify and "convert" that same js.Value to a Go value of type time.Time. This change doesn't appear to accommodate the bidirectional nature of the vert package. Ambitiously, if the "generic" feature of user defined bidirectional type mappings between Go and JS is fully support, I'd be willing to hold off on the native time.Time support but I'm not blocking on it if a fully flushed out implementation is contributed.