cleanup tiny bit

[cyberhck]

What I like about tinka is that it's very close to standard fetch, we are able to work with actual fetch (if we don't add any fancy middleware), and it's dependency free.

When I was working with the Response, I was surprised that it wasn't aligned with standard specs. Looking at FetchMiddleware, I see a few issues there.

First, it's not extending from standard Response (that was probably because Response wasn't available back then), now that it is, IFetchResponse should probably extend from Response and overwrite only .json() method since it's generic.

It also contains a cache key which I don't think belongs there,

I propose to fix this up, also looking at CacheMiddleware,

tinka/src/middlewares/CacheMiddleware.ts

Lines 32 to 36 in 5d7e72a

	export interface ICacheMiddlewareStore {
	setItem(key: string, value: string): void;
	getItem(key: string): string | undefined;
	removeItem(key: string): void;
	}

there's no way anyone can implement this interface in a decent manner, we should work with promises, this cache middleware looks like it's designed by only thinking about localstore in mind.

Let's deprecate CacheMiddleware, update the fetch response interface (maybe also request), once this deprecate happens, then we can drop support for Cache for now (no one is using it from what I know), and let users implement their cache on how they want, Cache is such a vast topic that it even makes sense to create a separate package with a lot of Drivers (which implements ICache interface)

cc @paibamboo

[cyberhck]

also the difficult part of CacheMiddleware is that it pollutes the original object, which means when you request:

const sdk = new Sdk();
sdk.user.get(1, {cache: {ttl: 60}});

What I'd prefer what's mock middleware is doing, adding a middleware and attaching handlers to that middleware, this means user after setting up cache once, never has to think about it.