Projects should not set HSTS preload

https://github.com/frappe/bench/blob/6aef163753c2ad96b7e0addf6da36691c9542eb8/bench/config/templates/nginx.conf#L54

The default NGINX SSL configuration sets HSTS (which is OK, if confusing for local development if you set up HTTPS then wonder why you can't access your local HTTP version of your site when the HTTPS isn't working). But it also sets 'preload' which software projects should not do (at least not by default) as once the site is up it is very difficult to remove _and_ it has potentially larger consequences than just for the Frappe site.

It also includes subdomains so if someone had Frappe on a HTTPS subdomain and another site on a HTTP subdomain, this might block access to the HTTP subdomain.

From https://hstspreload.org/
"If you maintain a project that provides HTTPS configuration advice or provides an option to enable HSTS, **do not include the preload directive by default**. We get regular emails from site operators who tried out HSTS this way, only to find themselves on the preload list without realizing that some subdomains cannot support HTTPS. [Removal](https://hstspreload.org/#removal) tends to be slow and painful for those sites.

Projects that support or advise about HSTS and HSTS preloading should ensure that site operators understand the long-term consequences of preloading before they turn it on for a given domain. They should also be informed that they need to meet additional requirements and submit their site to [hstspreload.org](https://hstspreload.org/) to ensure that it is successfully preloaded (i.e. to get the full protection of the intended configuration)."

Start at bench/config/templates/nginx.conf near line 54 and review the default NGINX SSL configuration. Verify that the default HSTS behavior does not enable preload or include subdomains, and inspect the generated configuration to confirm the resulting header matches the intended behavior.

Written by the indexing model from the issue text.