Add type definitions

[demurgos]

This commit adds type definitions for plugin-error.
These types are adapted from the ones of gulp-util.
The main changes are that the types are more based on the
documentation instead of the implementation. It means that the error
property used internally is no longer exposed as an option (it matches
the tests). It also tries to prevent the use of the plugin option if
it will be overriden. It also adds support for inference of additional
properties from wrapped errors when the second argument is a real error.

This commit also adds some tests for the types. It just runs the
compiler with the noEmit option and checks for errors.

I had to set explicit versions for the test dependencies (instead of *)
because their latest versions require Node 4+ (the CI runs on Node 0.10, 0.12 and 3).

I tested it locally and as a replacement for gulp-util for the gulp-tslint plugin.

Closes #5

[demurgos]

@phated
Could you take a look at it?
Among the most popular gulp packages relying on gulp-util, it seems that only gulp-tslint is blocked by the lack of types for plugin-error. It would also help gulp-typescript which currently has its own duplicated types hosted on its repo. The gulp-tslint author notified me that he is ready update its plugin so merging and publishing this PR would allow a fix for gulp-tslint.

[phated]

Looks great! Thanks @demurgos - I'm going to merge this but not publish until I do some maintenance on the repo.

[demurgos]

Could you publish the current version as a semver-minor update?

I know that you'd prefer to first do some maintenance, but it's better to not block publication if you don't have time to do it at the moment.
I could also try to help you with the maintenance if possible. I can't add integration with third-parties, but can update the README or apply some changes (code style?). I could try to replicate what you have on some reference repo (Vinyl for example?).

[phated]

@demurgos I actually have the major version bump ready but was waiting on some licensing feedback. I didn't get a chance to finish it once I got the response but I can later today (when I get back to my other computer).

Side note: a semver-minor when below 1.0 has the same semantics of a major above 1.0 - so in this case, a semver minor is the same as bumping to 1.0

[demurgos]

Ok, thanks for the update.
(I was proposing a semver minor to let 1.0.0 be the version with your changes, but yes a semver patch could have been better since there is no implementation change)

[phated]

@demurgos published as 1.0.0