Refined .call() and .construct() API

[dherman]

This PR experiments with a refined .call() and .construct() API for JsFunction, based on the ideas we came up with in #796 as well as the idea of overloading result types to make downcasting more concise and ergonomic. The changes include:

• Uses the Arguments trait instead of IntoIterator, which still works for Vec and arrays but also heterogeneous tuples
• Overloads and downcasts to the result type
• Adds the .exec() method for discarding the result when it's not needed

This generally leads to more concise and readable code. But it has a few downsides:

• The difference between arrays and tuples is subtle: heterogeneous vs homogeneous types, and the fact that empty arrays ([]) tend to lead to inference errors where empty tuples (()) usually work, could both be confusing especially to newer Rust programmers.
• You still tend to end up having to compute arguments in previous statements in order to use cx, whereas the method chaining approach in Arguments builder API #796 circumvents this issue.
• Downcasting with turbofish requires three blank type parameters (_) to be passed after the result type.
• Always downcasting, even when the result type is JsValue, may not be able to be made zero cost. (But this is probably most often needed for discarding the result, in which case .exec() avoids the downcast overhead.)

I wanted to implement this before we finalize the builder APIs, so that we can consider the complete set of function call APIs holistically.

[kjvalencik]

Suggested change

	f.call::<JsNumber, _, _, _>(&mut cx, null, [arg])
	f.call(&mut cx, null, [arg])

[kjvalencik]

Suggested change

	get_utc_full_year_method.call::<JsNumber, _, _, _>(&mut cx, o, ())
	get_utc_full_year_method.call(&mut cx, o, ())

[kjvalencik]

Suggested change

	f.call::<JsNumber, _, _, _>(&mut cx, null, [arg])
	f.call(&mut cx, null, [arg])

[kjvalencik]

Suggested change

	get_utc_full_year_method.call::<JsNumber, _, _, _>(&mut cx, o, ())
	get_utc_full_year_method.call(&mut cx, o, ())

[kjvalencik]

Rust is sometimes able to optimize iterators a little better. SmallVec implements from_iter, so it can be used with collect.

Suggested change

	let mut args = smallvec![];
	for arg in self {
	args.push(arg.upcast());
	}
	args
	self.into_iter().map(|v| v.upcast()).collect()

[kjvalencik]

Suggested change

	let mut args = smallvec![];
	for arg in self {
	args.push(arg.upcast());
	}
	args
	self.iter().map(|v| v.upcast()).collect()

[kjvalencik]

const generics will require a fairly recent version of Rust (1.51, released in March). Given that we're copying anyway, maybe this only needs to be implemented over slices?

I think this and Vec could be deleted and only leave an implementation for &[Handle<'a, T>].

[kjvalencik]

@dherman One thing that doesn't feel super great about this is that we're always copying all of the elements, even though for slices, we could be using it directly without allocations.

[kjvalencik]

I think this would result in better performance if the items were expanded in the smallvec macro instead of pushing one by one.

[dherman]

I chatted with @kjvalencik and it seems like call_with() and call() are so close in functionality that it's not really worth having both. It seems more valuable to have a lower-level primitive that avoids copies and unnecessary coercions, but it's not clear that it's worth using up the name call() for it.

So a conservative plan for now is:

• Implement call_with() and construct_with() as the high-level ergonomic API.
• Deprecate call() and construct() <== meh, even this is premature
• Write a migration guide and get early user feedback to make sure the migration is feasible

We can explore a lower-level, zero-copy primitive that takes a reference to an array of values and passes that directly to N-API, and we can decide later if we want to call that .call() or something that suggests that it's lower level.