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.

[AlexV525]

@Leptopoda Thanks for your contribution, and of course they are welcomed!

Regarding the breaking part, a detailed migration guide would be helpful for the process. Also you may want to check the compatibility with dio_cookie_manager and other downstream packages to learn their cases.

About RFCs, it would be great if you could ref them as comments directly in the code, so we can always follow them.

[AlexV525]

Sorry it has been a while since the last review. Could you fix all the tests?

[provokateurin]

The linting is failing, not the tests

[AlexV525]

Yeah and the lints too

[Leptopoda]

Sorry for my inactivity. The CI should be passing now.
Our own implementation is finished and already deployed to our users. If you are open for bigger refactors and enhancing the code readability of the current code I'll happily contribute it.