Fix TypeScript type inference for functions passed to map

[Avaq]

This pull request tries to fix #455

I've started with a tsd setup to defend against regressions to before #401 and #403. Run npm run test:types to check that your typings have not introduced a regression.

For context, here's the current TypeScript typings for map:

Fluture/index.d.ts

Lines 137 to 143 in 2f12660

	/** Map over the resolution value of the given Future or ConcurrentFuture. See https://github.com/fluture-js/Fluture#map */
	export function map<RA, RB>(mapper: (value: RA) => RB): <T extends FutureInstance<any, RA> | ConcurrentFutureInstance<any, RA>>(source: T) =>
	T extends FutureInstance<infer L, RA> ?
	FutureInstance<L, RB> :
	T extends ConcurrentFutureInstance<infer L, RA> ?
	ConcurrentFutureInstance<L, RB> :
	never;

Also relevant, the type of pipe:

Fluture/index.d.ts

Lines 36 to 37 in 2f12660

	/** Apply a function to this Future. See https://github.com/fluture-js/Fluture#pipe */
	pipe<T>(fn: (future: FutureInstance<L, R>) => T): T

[Avaq]

I've pushed an additional set of test assertions to check that the requirements stipulated in #455 are met. As of yet, these assertions fail and I have been unable to find a type definition that causes the assertions to pass.

[Avaq]

Of course, if I replace the entire TS definition for map with the following, then the new assertions pass:

export function map<RA, RB>(mapper: (value: RA) => RB):
  <L>(source: FutureInstance<L, RA>) => FutureInstance<L, RB>

The definition above is functionally equivalent to the definition that was used in Fluture v11. There is no support for the ConcurrentFuture type, and so while all the other assertions now pass, the ones for the ConcurrentFuture type fail (#401).

[Avaq]

Should I release this with a major version bump? I would prefer not to, but I find that when changing TS types, it usually probably breaks something for someone.

[Avaq]

We've kind of "narrowed" the type of map here from map(f: (x: unknown) => B) to map(f: (x: A) => B) where A can be inferred from the second argument. Narrowing a type is usually a breaking change. In this case, we're narrowing the type to exactly what the user would want, though. So chances are users will have no problems. Unless a user gave an incorrectly typed function to map, in which case this change will suddenly break their build. Although in the latter case one might argue that their code was already broken, they just didn't know it.