fix(versions): general refactors to handle flag edge cases

[kanadgupta]

🚥 Resolves RM-7747

🧰 Changes

Per RM-7747, our versions:create and versions:update commands don't properly set boolean values correctly, for example:

# since `false` is a string that isn't properly cast to a boolean
# it sets the flag to `true` 😬
rdme versions:update --beta=false 1.0.1

# this should fail since it's neither 'true' nor 'false', but it doesn't
rdme versions:update --beta=yo 1.0.1

The code for prompting the user and constructing the request payloads is all very messy and hard to follow, so this PR utilizes the incredibly handy prompts.override method to vastly simplify things and improve readability in a few places, which in turn fixes a few weird bugs:

• Created a castStringOptToBool that properly takes our string command line opts and sets them to their boolean counterparts. Now when a user passes --beta=true or --beta=false, we actually pass those into the payload as proper booleans! We also now throw an error if the value for these flags is a string other than true or false.
• Slight improvement (and maybe fixed a bug?) w.r.t. the prompt DX in the versions:update command: if a user doesn't want to change the name of the version, they previously had to re-enter the name of the version. Now if they just hit enter, we'll default to the existing version name.
• If the user doesn't pass the rarely used codename option, we no longer send the codename field as an empty string in the request payload
• For some reason the versions:create command was missing the deprecated flag? This PR backfills that.
• Renames a few functions and variables to be more sensible
• Lots of tests 🧪

🧬 QA & Testing

If tests pass then we should be good, but feel free to try a few flows with the versions:create and versions:update commands to see if everything works as expected.