replace calls to werkzeug.urls with urllib.parse

[davidism]

Use urllib.parse functions instead of our own implementation. Deprecate all of werkzeug.urls except for uri_to_iri and iri_to_uri. My benchmark shows a 35% speedup in routing and responses, 8% from replacing most calls, the rest from refactoring the implementations of the iri functions. fixes #2600, fixes #2406

The only thing that still needed an (internal) wrapper was urlencode, since the router and test client might pass MultiDict or dict to it, and also expect None values to be discarded.

Since I was replacing all uses of quote, I also took the opportunity to review what characters are being treated as safe from percent encoding. We were not being particularly consistent or correct about it. Now all uses of quote for URLs use safe characters for the specific part of the URL being quoted, based on the WHATWG URL Standard, which fixes #2601. For quoting the filename* option in send_file, use the RFC 5987 attr-char set, which fixes #2598. iri_to_uri avoids quoting any ASCII printables, since it's assumed they're intentional at that stage. uri_to_iri unquotes as much as possible without changing how urllib.parse.urlsplit will split the URL.

As a start to #2602, deprecated passing a tuple or bytes to the iri functions.

Another side effect of inlining some helper functions is that parsing application/x-www-form-urlencoded form data now uses max_form_parts like multipart/form-data. Not as important in this case, but may as well be consistent.

[ThiefMaster]

Another side effect of inlining some helper functions is that parsing application/x-www-form-urlencoded form data now uses max_form_parts like multipart/form-data. Not as important in this case, but may as well be consistent.

As mentioned on Discord, I feel like change this is actually a bug that should possibly be reverted:

• Unlike parsing multipart data, the overhead of parsing url-encoded form data is tiny (less than 2s for a million fields vs 25s for the same amount of multipart fields)
• It's not really that uncommon to have POST data with many values, especially compared to equally huge multipart requests
• Parsing urlencoded form data is more similar to parsing JSON data than to parsing multipart data - and AFAIK the default JSON parser has no such limit either.
• "parts" is a term that's usually just used when it comes to MIME/multipart data, not random form fields
• the docstring of max_form_parts also only mentions "multipart parts"

[davidism]

Yep, I thought it would make sense to apply it consistently, but it sounds like only multipart is affected by the issue so I'm fine with reverting it for formdata.