Optimizing asyncio.Future by writing a cdef class extension of it.

I was looking at a few things that could be improved and one of them was internal objects that aren't interacted with all that much and that would be asyncio.Future I was thinking about writing a object based on the pure python version since the C version is primarly a reflection of it.

And since isfuture() is meant for checking if an object is a future instead of isinstance(fut, asyncio.Future) which should be discouraged to begin with so I think we can get away with it as long as we do what was done within The Handle and TimerHandle objects that were currently using where initializing winloop.Future throws an error. I'll possibly look into optimizing task objects as well in the future if this idea succeeds.

I think I could do a pull request on uvloop's side also if this succeeds at this as well.