Add environment variables using Belt CLI

[rakeshpetit]

In this PR, we add a new belt add env CLI command that sets up environment variable management in an Expo project using the EXPO_PUBLIC_ mechanism.

What the command does

• Installs dotenv as a dev dependency.
• Copies template files: .env.example, .env.test, jest.setup.env.js, and src/config/index.ts.
• Creates .env from .env.example if it doesn't already exist.
• Patches src/util/api/api.ts to replace the hardcoded GitHub API URL with EXPO_PUBLIC_API_BASE_URL.
• Patches jest.config.js to load jest.setup.env.js via setupFiles.

Refactoring existing notifications code

Reusable utilities were extracted as part of this work and applied to both env and notifications:

• src/util/patchFile.ts - generic read/search/replace/write function to patch existing project files.
• src/util/confirmToProceed.ts - interactive intro prompt shared across commands.
• handleCommitError moved to be used in multiple commands.

Both env and notifications command now have:

• Improved error handling using a try/catch with spinner.fail(error.message) so the terminal doesn't hang on errors.
• Multi-line user facing strings extracted to named constants for better readability of the code

[MalcolmTomisin]

I don't think having the dotenv package is a requirement for adding environmental variables to an expo project. One can load env vars in an expo project without another external dependency as long as the env vars are consistent with what is specified on Expo docs.
Furthermore, I am eager to understand if this is a feature Belt should have. I don't see the marginal utility to having this unless it is a part of a belt process. e.g. when setting up the expo project

[rakeshpetit]

I don't think having the dotenv package is a requirement for adding environmental variables to an expo project.

Nice catch. I will tweak this PR.

Furthermore, I am eager to understand if this is a feature Belt should have. I don't see the marginal utility to having this unless it is a part of a belt process. e.g. when setting up the expo project

Setting up env variables is something that happens in most mobile projects. As a CLI, this makes it quicker with one command including setting up test environments. Since we don't have a roadmap for Belt features, I felt this would provide some value. Should we get together and come up with a roadmap of Belt features as I'm keen to add better features providing value?

[codeofdiego]

We might need to check if the entry already exists in the .ignore file to prevent duplicates.

[codeofdiego]

I believe .replace will only replace the first occurrence, would .replaceAll be more suitable here?

[codeofdiego]

I realized this could open a door for injection, for now it is alright because the message being passed is hardcoded, but we might need to rethink thins.

[codeofdiego]

Looks good, I just had some minor notes.