feat: add flag type label

[AllanOricil]

This will enhance the way (flags | args) are displayed. Developers will no longer need to read the flag's description to grasp the type|format of value they have to use with a certain flag or arg. For example, when I read filePath I immediately understand that a certain flag require a file path.

Below you can see how docker cli does it

obs: I added a new property called typeLabel instead of using the helpValue because I did not want to force cli developers to use it, and because the variable name better describe what it is than helpValue

BEFORE

AFTER

To enable this render type CLI developers have to set oclif.showFlagTypeLabel to true in the package.json

When typeLabel is not defined, and oclif.showFlagTypeLabel is true instead of showing =<option> it is displayed string, or string... if multiple. It feels cleaner in my opinion.

---

When combining with the theme and indent features

[mdonnalley]

@AllanOricil Thanks for making this PR but I don't think it's something we want to move forward with. I have two main concerns:

1. I think it makes the help output too crowded
2. If I understand correctly, typeLabel would need to be added to every single flag. Otherwise, it would show something like --integer string (as an example), which is confusing. So I'm not sure how it's better than the existing helpValue property

[AllanOricil]

@mdonnalley my idea was to deprecate the other prop and eventually merge both into one. This way developers can decide what to show in their flags. In my opinion, I really think that showing directoryPath instead of <value> offers a much better dx. I also think the variable name is better than the current one.

edited: If you don't agree, or if the effort to replace the current attribute is too complicated, you can just close it. But you could see what devs prefer before closing it. Like, show some people around those pictures I posted above, and ask them which one they like the most.