Specify what happens when partitioned cookies collide with same-name unpartitioned cookies

[johannhof]

For example in browsers that have not blocked 3P cookies (yet) or when storage access is granted, we should say what the expected observable behavior is when an embedded context reads/writes a 1P cookie and a partitioned cookie with the same name. Talking to @DCtheTall I think that in Chrome it would currently store and send both cookies (i.e. the same name twice) but it would be good to have consistency and a clear definition of that.

[johannhof]

This follows from #38 and #51 with the assumption that partitioned cookies are accessible in non-partitioned embedded contexts as defined in #42.

[DCtheTall]

The Algorithm section addresses this concern:

Also, we would modify the first part of step 19 of the algorithm in step 5.4 to also include the partition-key in the list of cookie attributes to check, so that two cookies with the same name, domain, host-only-flag, and path can coexist in the cookie store if their partition-key values differ.

I have merged a PR against the partitioned cookies draft spec. I brought up this solution at IETF and no one had any objections, so I am going to close this and we can hash out any details when reviewing the spec.