Respecify cookieStore.delete(name) semantics

[aamuley]

Currently, cookieStore.delete(name) can only be called on a cookie where the rest of the uniquely identifying values (domain, path, partitioned) are the cookieStore API defaults

A developer may expect that if they set the following cookies:

cookieStore.set({name: "cookie1", value: "val", partitioned: true});
cookieStore.set({name: "cookie2", value: "val", path: "/v2"});
cookieStore.set({name: "cookie3", value: "val", domain: "sub.example.com", samesite: "none" });
document.cookie = "cookie4=val;" (executed at path /v2)

Calling cookieStore delete on each of these by name
cookieStore.delete("cookie[1-4]"); should work but it does not, the options that are different than the defaults are required to be specified with the cookieStore.delete(options) method

Is this actually intended behavior as it seems misleading and would make it particularly difficult to delete a cookie if we opted for a more limited cookieStore.get/All() that only returns a name and value as suggested in #241 and #238 and not the other unique options the delete method requires.

[annevk]

This seems reasonable to improve, provided there are sufficient tests to catch all the nuances. I would not expect websites to rely on deleting to not work.

For deleting to become more natural I suspect we need more of the options to default to some kind of wildcard. This is also needed for the Delete-Cookie HTTP header proposal. I suspect this will require two things:

1. Some API changes. At least how we handle the dictionary for delete() has to change.
2. Some kind of model change. Today we delete by overwriting a cookie. As we move to wildcarding and potentially delete several cookies with a single operation, we'd need new infrastructure.

cc @RupinMittal @DCtheTall @johannhof @bakulf