init_stripe does not appear to use .env

[azohra]

Expected behavior
init_stripe script runs using the key defined in .env and successfully returns the STRIPE_PREMIUM_PLAN_PRICE_ID to stdout, as defined in the README.md

Issue Reproduction steps
Run: deno task init:stripe

With:

# .env
GITHUB_CLIENT_ID=some_id
GITHUB_CLIENT_SECRET=some_secret
STRIPE_SECRET_KEY=some_key

and

# .env.example
GITHUB_CLIENT_ID=xxx
GITHUB_CLIENT_SECRET=xxx
STRIPE_SECRET_KEY=xxx

The user will be presented with the following error

Task init:stripe deno run --allow-read --allow-env --allow-net tasks/init_stripe.ts
error: Uncaught (in promise) Error: Stripe is disabled.
  if (!isStripeEnabled()) throw new Error("Stripe is disabled.");

Workaround steps
If you manually pollute the env with export STRIPE_SECRET_KEY=some_key and re-run the task deno task init:stripe you will be presented with the expected output

Task init:stripe deno run --allow-read --allow-env --allow-net tasks/init_stripe.ts
Please copy and paste this value into the `STRIPE_PREMIUM_PLAN_PRICE_ID` variable in `.env`: price_some_identifier 

Suggestions
I believe there is an opportunity to show off the robustness of .env in Deno when fixing this.

In particular

1. Location specific .env files such as .env.local and .env.production which can be loaded with Stripe test vs real keys.
2. Guards via .env.example where STRIPE_SECRET_KEY and STRIPE_PREMIUM_PLAN_PRICE_ID can be defined but loaded with allowEmptyValues: true, . null / empty / Falsey values would indicate a desire to not use the Stripe feature.
3. Increased use of --env in tasks such that we are always loading a .env

[azohra]

I have created an initial fix to get things working as expected. Suggestions are certainly in the nice to have category ❤️

Thanks for all the amazing work on this starter kit! Long live Deno! Long live Fresh!

[iuioiua]

Closed by #649. Thanks for helping!