Remove hard-coded configs in favour of env variables

[maximilianoertel]

Proposed changes

This PR removes hardcoded Firebase configuration values from the codebase and replaces them with environment variables. This change provides improved security by preventing accidental exposure of sensitive data and allows for easier configuration management across different deployment environments.

Additionally, this PR removes the .firebaserc configuration file, following Google's recommendation to exclude it from public repositories to prevent accidental exposure of sensitive information.

Key highlights

• Hardcoded config values are replaced with environment variables using the dotenvx library for encrypted configurations.
• Environment configurations are stored in a separate private repository and injected as a submodule in the env-configs directory.
• Forks of the project can easily set their own configurations by using the traditional .env file format supported by Vite at the root of the project.
• A .env.example file is provided at the root, serving as a source of truth for supported environment variables.
• A pre-commit hook is included to ensure no unencrypted dotenv files are accidentally committed to the repository.

Given the changes in how environment configurations are handled, this PR also restructures the npm commands available on the repo. More specifically, it removes all dev and build command variants in favor of two simple npm run dev and npm run build commands. This is done to avoid accidentally running the command with the wrong environment configuration and better support forks and alternative environments such as ROAR Clinic or Levante.

Should you wish to execute a dev or production build with an alternative env configuration, it is recommended to use the --mode flag, for example npm run build -- --mode production which would use the .env.production config.

This approach promotes better separation of concerns, improves maintainability, and enhances the overall security posture of the application.

Types of changes

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Refactoring (non-breaking change that does not add functionality but makes code cleaner or more efficient)
• Documentation Update
• Tests (new or updated tests)
• Style (changes to code styling)
• CI (continuous integration changes)
• Repository Maintenance
• Other (please describe below)

Checklist

• I have read the guidelines for contributing.
• The changes in this PR are as small as they can be. They represent one and only one fix or enhancement.
• Linting checks pass with my changes.
• Any existing unit tests pass with my changes.
• Any existing end-to-end tests pass with my changes.
• I have added tests that prove my fix is effective or that my feature works.
• If this PR fixes an existing issue, I have added a unit or end-to-end test that will detect if this issue reoccurs.
• I have added JSDoc comments as appropriate.
• I have added the necessary documentation to the roar-docs repository.
• I have shared this PR on the roar-pr-reviews channel (if I have access)
• I have linked relevant issues (if any)

Justification of missing checklist items

n/a

Further comments

n/a