Add Superset configs to setup process, and maybe reimplement that process

[MattTriano]

This will involve (at least) adding these to the process and having them output to a .env.superset file.

• ADMIN_EMAIL
• ADMIN_FIRST_NAME
• ADMIN_LAST_NAME
• ADMIN_PASSWORD
• ADMIN_USERNAME
• POSTGRES_DB
• POSTGRES_USER
• POSTGRES_PASSWORD
• SQLALCHEMY_DATABASE_URI (dependant, not user entered)
• SECRET_KEY

The setup process may be a bit cumbersome with these added to the process, and it felt barely maintainable when I initially implemented it. I should rethink the config secrecy strategy.

[MattTriano]

Upon revisiting that process, it was actually pretty easy (for me, the original implementer) to add new configs, but it would be rather difficult to write clear documentation so that someone else could also easily extend it in a fork. In any case, I added a dev mode to make it easier for such forkers to experiment with adding env-vars without having to hide their existing .env files.

This current implementation shields the user from a lot of potential credential-related bugs, such as:

• escaping special characters in database URLs/connection strings (although maybe I should have used urllib.parse.quote_plus() instead of just urllib.parse.quote()),
• producing database connection strings (like the above) from other env-vars,
• puts data warehouse database credentials in both the airflow .env file (as DWH_POSTGRES_xyz, for use in the connection string the Airflow containers need to set up the db connection via env-var rather than having the user manually define the connection through the UI) and in the separate env.dwh file (as POSTGRES_xyz), and
• automatically creating a Fernet key (for encrypting passwords and connection configs for Airflow), putting the user's uid into the .env (so that airflow has permission to save and update data files on the host system), and a SECRET_KEY (so that the flask webservers serving both the Airflow UI and Superset UI on the localhost don't treat the other as a cross-site request forgery attacks).

I still think there's got to be a better way to do this than having a user slog through 15+ prompts where they have to enter passwords, but I'm very pleased by the amount of complexity my implementation shields the user from.