refactor the CookieJar interface for more implementation independence

[Leptopoda]

Hi there and thank you for this package. I hereby suggest a few changes to the interface of the CookieJar class. We wanted to implement a custom cookie storage backend in sql and ended up writing a custom CookieJar instead of just using a custom Storage.

We did observe that the api is quite biased towards the DefaultCookieJar implementation and not really considering other implementations. We decided to go with:

• an api that can handle both synchronous and asynchronous implementations by using FutureOr
• an api that is implementation independent by not requiring the variable ignoreExpires that not every cookie store needs (we strive for RFC compliance so we do not need the option to ignore the expiration).
• replacing the delete with a deleteWhere function so users of the api can decide with higher precision what cookies they want to be removed.
• implementing an endSession function to remove non persistent cookies as described in the RFC

This is just a proposal and we are open to talk about changes. We hope you consider these changes even if they are breaking. Obviously there are less breaking ways to achieve this like keeping around the delete function and just deprecating it for now. We are also open to upstream the rest of our RFC compliance focused code if you are open and interested in further changes.