Rename extension traits for Cookies and QueryString

[secretfader]

As discussed in #187, functionality of extension traits be identifiable by import path, and the trait itself should be named after the type it extends.

To satisfy those constraints, querystring::ExtractQuery becomes querystring::ContextExt. Similarly, cookies::CookiesExt is now cookies::ContextExt.

Ideally, these changes will land before #162.

Motivation and Context

To align with Rust best practices and the direction of current project discussions.

How Has This Been Tested?

Current tests pass after being modified to import new types.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

[prasannavl]

@secretfader This looks good to me!

However, this is a breaking change. So, would rather mind holding off on this until #162.

• Let's introduce the PR(s) for RFC: isolating a stable core #162. Then since the cookies bit will get separated anyway, we should be free to change that. Perhaps, you could take the tide-cookies and do it as a part of that?

[secretfader]

@prasannavl That's one way to handle this, and I'm certainly open to it. Discussions with @aturon in Discord seemed to indicate they hoped to land these changes alongside RFC #162 (which is also a breaking change).

I don't care too much when this PR goes in. That said, if we're making the decision to not merge because it has a breaking change (and we're discussing other breaking changes to be merged shortly afterwards), is there a significant difference between including it now to potentially reduce the surface area of other PRs and waiting until after they land?

I'd like to hear your reasoning on why merging later is the better option.

[prasannavl]

@secretfader - Just opened - #219. Hopefully, this helps clarify my motivations on to keep it separate.

• Precursor: Tide core isolation revamp #219 despite seemingly a complete revamp of the organisation is a non-breaking change.
• Now the next step would be move bits out of tide into it's own crate.
• My rationale was that you could now use this extraction opportunity to make these changes as a part of it, since it's going to be a new crate anyway.

[secretfader]

My rationale was that you could now use this extraction opportunity to make these changes as a part of it, since it's going to be a new crate anyway.

master has already moved past a point where it would build with an 0.2 version dependency on Tide. Yes, I'm introducing a breaking change, but it isn't the first since our last release (which would make your opposition far more valid).

I don't see why this PR has to wait until #219 lands, other than for convenience. Integrating a smaller change like this into your roll-up isn't significant.