Consider dropping HSTS preloading

[florimondmanca]

Prompted by https://github.com/encode/httpx/issues/1025#issuecomment-661269344

Issues like #1025 should prompt us to reconsider whether using HSTS preloading from a server-side client (introduced via #151) is a sensible thing to do at all.

Key points of reasoning here:

• While it mimics the way browsers behave, and hstspreload is a super valuable library, from a UX perspective it can lead to ambiguous behaviors (#896) and cases when you really don't want HSTS preload to kick in (like in #1025).
• Crucially, from #124 it seems that HSTS preloading was introduced as a way to tackle "schema-less URLs". As of today HTTPX requires a schema on URLs, so if it was the initial motivation then it is now irrelevant. Besides, we can assume that developers are generally very aware of their choices to use http:// vs https:// on the server-side (as opposed to browser users just entering the domain name without a schema).

Some options are:

• Add a toggle so that HSTS preload becomes opt-in or opt-out.
• Drop HSTS functionality entirely.

Given all the context points above, we might want to just go with option 2).

[StephenBrown2]

My vote is for Add a toggle so that HSTS preload becomes opt-in, though for 1.0 it might be better to reduce the surface area and drop it entirely.