Refactored install command

[kevinmeijer97]

Changed the flow for the install command a bit, also added the configuration for the User model so we don't need #90 anymore.

The flow of the install command now is as follows:

• We're starting with setting up Statamic by running the statamic:install command followed up by adding @php artisan statamic:install --ansi into the post-autoload-dump, as Statamic's install command doesn't do that.

Next we setup everything for the user by:

• Setting the User model from the rapidez/statamic package in the auth config.
• Checking if the user migration exists, if not we get it from the Laravel repository.
• We change some config files and to comply with what's needed according to https://statamic.dev/tips/storing-users-in-a-database#in-an-existing-laravel-app
• We run the statamic:auth:migration command.

Now we setup everything for the Eloquent Driver by:

• Publishing the config files and changing the default table_prefix
• Calling the statamic:install:eloquent-driver command to configure the Eloquent Driver

At last we ask the user to:

• Configure the multisite
• Publish the Collections, Blueprints, Fieldsets & Views from rapidez/statamic
• Make a Statamic user

Furthermore i changed the version of rapidez/sitemap to ^3.0 for it to work with Rapidez v3.

[kevinmeijer97]

Made a PR to Statamic so we can select specific repositories on the install command for the Eloquent Driver.

[royduin]

It feels weird to have this file here with a namespace that doesn't match. Maybe create a stubs directory just like Laravel handles that?

[kevinmeijer97]

But the namespace matches and we dont actually publish it to the project, we load it from this repository.
See src/Commands/InstallCommand.php:85

[royduin]

Ah I see, but it's likely that the end user want to edit the user model.

1. Maybe keep it as a stub and publish it? But what if there is already a model?
2. Keep it here and extend it within the project?
3. If there is already a user model; that file still needs this changes.

So maybe option 2 so we can simply change the "extends ..." in case 3 so it will extend the model from this package instead of the framework? project -> package -> framework

[kevinmeijer97]

Yes 2 seems fine to me as well.
But during the install command do we just keep it in the package?
So when a user wants to extend it into their project, they can do it themselves.

[royduin]

If you run the command twice, it doesn't mess anything up?

[kevinmeijer97]

If you run the command twice, it doesn't mess anything up?

Added some checks and changed some stuff around to make sure nothing breaks when running the install command multiple times.