Move starter project for init task into dbt repo

[jtcohen6]

Rather than storing the starter project cloned by dbt init in a separate repository (dbt-starter-project), we should store that code directly in the main dbt repo.

Originally, we stored the starter project separately so that we could make changes to it more frequently than we could cut new releases of dbt. Instead, over the past four years, we've cut many more releases to dbt than we have merged updates to the starter project :)

This helps us avoid annoying behavior when a specific dbt version requires a specific breaking change to the starter project (e.g. dbt-labs/dbt-starter-project#8, dbt-labs/dbt-starter-project#10).

We could take one of two implementation approaches:

1. Store starter project files in the https://github.com/fishtown-analytics/dbt repository, dbt init works more or less the same by cloning from the repo @ the tag of the current dbt version
2. Ship starter project files within each version of dbt, rewrite dbt init to just copy files (no cloning from remote)

Questions

• Should we allow adapter plugins to override / reimplement the starter project? We already enable them to provide a sample profile for first-time users, which enables dbt init --adapter [adapter] (mostly: dbt init --adapter default to the available adapter #2814).

Describe alternatives you've considered

• Continue maintaining separate repo with starter project. Develop more rigorous plan for versions + tags.

[leahwicz]

• IDE does not use the init command
  • Check what their init command does vs what we do
  • Why are they doing that?

[ssassi]

Have you considered using https://github.com/cookiecutter/cookiecutter?

[jtcohen6]

@ssassi Yes, we were just talking about it over in #3474 (which was just merged, and really closed this issue). I think there's a lot cookiecutter could get us. It's one step beyond what dbt init needs to do today, but if/as we add more complexity, we may decide it's worth the switch.