fix: downgrade urfave/cli to v1 to enable more flexible parsing

[danxmoran]

Closes #147

I've confirmed that rebasing #150 onto this branch fixes the breaking change (I can pass the stack ID before or after the -f flag).

[williamhbaker]

Everything looks good in the code as far as I can tell, but I have a higher level question as well - Is the issue with v2 breaking the old CLI examples really just related to examples - docs examples I'm guessing? I'm thinking along the lines of updating the examples vs. using an older version of urfave.

Updating a bunch of docs wouldn't be very much fun but that might have some pros instead of working with an older/not maintained package. If there's more significant breakages that would occur with the new behavior maybe it would outweigh that though.

[danxmoran]

Is the issue with v2 breaking the old CLI examples really just related to examples - docs examples I'm guessing?

Yes, across our public docs, help text, and (I'd guess) blog posts. I think it's something we could eventually phase out w/ proper deprecation notice, but I think it'd be a big lift to update everything in time for the new CLI release (esp. given the time pressure). I think minimizing the number of big incompatibilities will be important to get people to go through the effort of migrating to the new version; we're still paying for some big mismatches between v1 and v2, I don't want to add another layer of problems between v2.0 and v2.1.

I checked the release dates of urfave/cli. v2.3.0 and v1.22.5 were released within a day of each other, so I don't think we're regressing to a version that hasn't seen any maintenance.

[williamhbaker]

Makes sense to me, especially regarding reducing the friction from v2.0 to 2.1!