Similar issue as in https://github.com/laravel/prompts/pull/146. To make packages like `symfony/var-dumper` available globally you prepend the global Composer autoload.php like so:
```
// php.ini
auto_prepend_file = ${HOME}/.composer/vendor/autoload.php
```
In Valet this can result in
```
( ! ) Warning: Constant VALET_HOME_PATH already defined in ~/.composer/vendor/laravel/valet/server.php on line 12
Call Stack
# Time Memory Function Location
1 0.0354 571296 {main}( ) .../server.php:0
2 0.0380 571488 define( $constant_name = 'VALET_HOME_PATH', $value = '~/.config/valet' ) .../server.php:12
( ! ) Warning: Constant VALET_STATIC_PREFIX already defined in ~/.composer/vendor/laravel/valet/server.php on line 13
Call Stack
# Time Memory Function Location
1 0.0354 571296 {main}( ) .../server.php:0
```
- Extract much of server.php into a `Server` class
- Move all but the Laravel and Basic drivers into a subfolder
- Load all but the Laravel and Basic drivers via glob
- Add `beforeLoading` hook to simplify the `frontControllerPath` method for some drivers
After running `valet directory-listing on` if a URI points to a directory that exists, but the requested file cannot be found in that directory, a directory listing will be displayed.
A 404 will still happen if the project directory cannot be found.
Running `valet directory-listing off` makes a 404 display (without a listing) if the requested file cannot be found.
Supercedes and closes#349 and closes#587
To support smarter detection of static-file detection and allow Valet to mutate the URI for externally-hosted assets (save bandwidth and local storage etc), detecting any custom-inserted environment variables needs to happen slightly sooner in the execution cycle.
Discovered this issue when troubleshooting #729 and #247. While they have other workarounds, this PR simplifies things, and potentially makes custom drivers slightly easier too ... when the use-case applies.
Fixes#144
".test" or ".dev" is really a TLD, not a "domain" in the conventional sense.
Changing the command to `valet tld` more accurately reflects the purpose of the command (to set or get the configured TLD served by Valet)
The use of `valet domain` is currently preserved as an alias for `valet tld`, but will be removed at a later date.
