Allow custom env file paths

[bcherry]

I'm working on a swift example app for the voice assistant and it needs to get the sandbox ID loaded in, but none of the API keys. The Android example app does this with a global variable that gets overridden via sed, but the approach is brittle and a little messy.

In Swift, the best approach is to use xcconfig files, which can be imported in as build settings. It turns out that xcconfig files basically have the same format as env files, so we can just treat them as the env files for this type and take advantage of our existing env-population code. The only issues are
a) the files need to be in a subdirectory
b) it's best to give them the .xcconfig extension (although not strictly necessary, it can work without this)
c) we should not install the project secrets into them

This PR resolves these issues by allowing you to specify custom paths to these files. I added support for these to the taskfile's vars field and also to the app env command for completeness.

Here's a sample taskfile using these new properties, which I have tested and works exactly as desired. I haven't evaluated it yet but I'm hopeful that we can adopt the same method in android, react native, and flutter.

[rektdeckard]

I wholeheartedly support the ability to specify the --output and --example input, but I should point out that instantiating the env does not copy LiveKit project secrets. It reads in the example and replaces only the ones present that it recognizes. So the solution to not including secrets is...not to specify them in your example.

[bcherry]

@rektdeckard ah that makes perfect sense. it wasn't clear to me from the code, but I tested it and you are absolutely right! the only case it would fill them anyways is if no .env.example exists, but in this case I'll have an example file so it should work.

I simplified that option away and made some other tidies.

[rektdeckard]

Other than comments, looks good!