Initialize parseURL and parseQueryString lazily

[wilzbach]

This makes the last two options of HTTPServerSettings lazy. As mentioned before, lazy intitialization costs us constness of the methods.

[wilzbach]

There's a bit of code that expects these variables to be mutable (hence ref), e.g.

http/vibe/http/auth/basic_auth.d(100,4): Error: function vibe.http.server.HTTPServerRequest.username () is not callable using argument types (string)
http/vibe/http/auth/digest_auth.d(119,4): Error: function vibe.http.server.HTTPServerRequest.username () is not callable using argument types (string)
http/vibe/http/server.d(391,2): Error: function vibe.http.server.HTTPServerRequest.path () is not callable using argument types (string)
http/vibe/http/server.d(392,2): Error: function vibe.http.server.HTTPServerRequest.queryString () is not callable using argument types (string)
http/vibe/http/server.d(393,2): Error: function vibe.http.server.HTTPServerRequest.username () is not callable using argument types (string)
http/vibe/http/server.d(394,2): Error: function vibe.http.server.HTTPServerRequest.password () is not callable using argument types (string)

[s-ludwig]

I'd say lets postpone the URL/path part for now, as the best solution may still shift w.r.t. the path/URL implementation. The query string makes sense in any case, though.

What I think makes sense for parseURL even now, is to always parse the URL, eagerly (it's de-facto @nogc and very lightweight), but to keep req.path tied to parseURL for now, because that actually may allocate memory.

But .path is ugly anyway. With vibe-core, this could be an InetPath, which doesn't allocate upon construction, and would also behave correctly w.r.t. URL encoding. Currently there are issues with encoded slashes within path segments (in the router and arguably also in the file server). So a transition path to InetPath should be the goal (not sure if alias toString this; in InetPath is a good idea).