Throw TypeError when too few parameters are passed to Futures API

[lanthaler]

If you have a function like

Future expand (JsonLdInput input, optional JsonLdOptions options);

and you call it without any parameters (expand()) it should throw an TypeError instead of returning a Future. You have to keep in mind that these things will most of the time be implemented in C++. You can't just omit a parameter in that case.

[dlongley]

I'll accept this pull request... but it's still not clear to me that this is the desired behavior. When writing node.js-style functions that raise errors for invalid options, you pass those errors via the callback, you don't throw them. Will people using Futures also expect all errors to propagate through a rejection callback? There seems to be some degree of inconsistency here. Do you throw errors that occur during the creation of a Future or do you always create a Future, but create one that will be immediately rejected? This isn't language-specific, a C++ implementation could do the same thing ... always generate a Future but reject it if the parameters provided to the call that creates the Future are invalid.

I like the consistency w/node.js on this issue, but maybe Futures will depart from that. In any case, I'll merge this even though it causes duplication for Futures APIs that wrap node.js code (another unfortunate drawback).