feat(twilio-run): restructure configuration

[dkundel]

This PR aims to restructure the way configuration is handled by dropping .twilio-functions files in
favor of a dedicated config file and a deploy info cache file.

BREAKING CHANGE: Drops support for .twilio-functions files and internally restructures activate
files to promote

fix #166

Contributing to Twilio

All third-party contributors acknowledge that any contributions they provide will be made under the same open-source license that the open-source project is provided under.

• I acknowledge that all my contributions will be made under the project's license.

[philnash]

A lot of this seems to be the consolidation of flags, which is a nice refactor. Can you point out the parts where the .twilio-functions file format has changed to the .twilioserverlessrc version? Where is the impact of this change? Thanks!

[dkundel]

The big changes are:

1. The .twilioserverlessrc file supports various formats incl json5 (default), yml and JS
2. I removed more complex nesting capabilities (previously you could for example specify config per environment per account). Now you can only do either. The previous was more flexible but both harder to parse and harder to explain.
3. The .twilioserverlessrc file will never be modified by the Toolkit. Instead the build info gets written into a .twiliodeployinfo file on a per account basis. It's the first step on removing some of the pain points we've seen when working with multiple Twilio accounts on the same project. The .twilioserverlessrc file can be checked in but the .twiliodeployinfo file should be added to gitignore by default (will add that at a later point)

And yes I consolidated all flags. That should hopefully help us also use flags in a more consistent matter.

[philnash]

Any reason to not use JSON.stringify here?

[dkundel]

Because I'm adding comments since it's JSON5

[philnash]

Ah, in templateFlagAsConfig, got you. Shame JSON5 doesn't make it easier to actually work with the comments it permits.

[philnash]

Splitting this to the two files, publicly shareable and local data, is definitely going to be a good thing.

You were right in your comment about this being a difficult part of the code base! I can't see anything wrong, but you know it better than me.

You have this as draft. Was there more work to be done?

[dkundel]

I'm still adding tests and I want to have a graceful migration option as well.

[philnash]

I have a couple of questions. I'm sure nothing is a blocker.

[philnash]

👍