Add a VRAM column to the cloud table output

[jojje]

Add a VRAM column to the cloud table output

Adds a VRAM column to the cloud sub-command output (resolves #183)

Example:

$ runpodctl get cloud

GPU TYPE                        VRAM GB MEM GB  VCPU    SPOT $/HR       ONDEMAND $/HR
1x AMD Instinct MI300X OAM      192     283     24      Reserved        Reserved
1x NVIDIA A100 80GB PCIe        80      117     8       0.600           1.190
1x NVIDIA A100-SXM4-80GB        80      125     16      0.890           1.590
1x NVIDIA A40                   48      50      9       0.240           0.350
...

I think we need to discuss how this column should be presented, and where, so consider the PR in the current form in a state of "here's a working implementation, let's discuss what's good or bad about it". I'm happy to change this to fit the project vision.

Now, there are three obvious questions that need settling:

1. Adding the new column to the default output may be a breaking change for some users, as they may have setup grepping / regexp (screen) scraping automation in their workflows to extract some specific data from the existing cloud output.
2. Should VRAM be presented by default, or as yet another option that allows users to explicitly "opt-in"?
3. Where (column index) should this column be added?

All three questions center on the same concern; backwards compatibility. If the project has a strict "don't change the default output" (risk breaking screen scrapers), then the flag option seems the only viable option. On the other hand, if the project's focus is a good set of sensible defaults to minimize the cognitive load and address the users' needs as well as can be by default, then that would indicate the first option in No 2 to be the preferred one.

In either of the two options No 2 highlights, the column location in No 3 is still something that must be decided on.
Personally I'd prefer to see VRAM right after the GPU type, since that tells me all I need to know; How fast is the GPU (will it complete my task in time), and how much data can I fit into it. If either of those constraints are not met, then I can't move forward with an initiative. The rest of the columns present secondary (lower priority) concerns. As such that would merit the two most important columns be listed first.

But again, I'm open to other perspectives on this. What do you think, current good enough or would you want to see something changed?

How I tested it

Interactively with debugger.