feat: list metadata/-types stdout is table

[WillieRuemmele]

What does this PR do?

moves regular output into a table for
list metadata
list metadata-types

What issues does this PR fix or reference?

@W-6015646@

[mshanemc]

I think you gotta choose between hardcoding the columns OR scanning the full results set to build the Set of fields for the columns.

They could share a function to do that.

and then I think you probably want to capitalize them and split with spaces to make it look nicer than

createdById: string;
createdByName: string;
createdDate: string;
fileName: string;
fullName: string;
id: string;
lastModifiedById: string;
lastModifiedByName: string;
lastModifiedDate: string;
manageableState?: string | null | undefined;
namespacePrefix?: string | null | undefined;
type: string;

wouldl provide

[mshanemc]

the type says that suffix is potentially undefined. If that's true (?), and the first item didn't have a suffix, then the suffix column wouldn't exist even if other items did have one.

[mshanemc]

Suggested change

	this.table(
	data,
	{
	key: { header: 'Field' },
	value: { header: 'Value' },
	},
	{}
	);
	this.table(
	data,
	{
	key: { header: 'Field' },
	value: { header: 'Value' },
	}
	);

[mshanemc]

Suggested change

	this.table(
	data,
	{
	key: { header: 'Field' },
	value: { header: 'Value' },
	},
	{}
	);
	this.table(
	data,
	{
	key: { header: 'Field' },
	value: { header: 'Value' },
	}
	);

[mshanemc]

FileProperties also has 2 potentially undefined fields. If the first item doesn't have them, those columns will be missing from all the other items that might

[mshanemc]

QA:
org list metadata-types -o hub
✅ works, columns look fine
🎨 I think these should be sorted by Xml Names. I'd also maybe alphabetize the childXmlNames (nit)

./bin/run.js org list metadata -o hub -m CustomObject
✅ works
❌ type column is lowercased. I'm not sure it should be there at all (is there a case where it wouldn't just be the type you just asked for?)

💡 I only see Id and Namespace Prefix when there's a Manageable State. I wonder if there should be 2 or 3 tables, grouped by Manageable state, so that the table without manageable state doesn't need those fields?

🎨 I think a reasonable sort order for these would be state, prefix (unless you decide to do separate tables), full name.
🎨 I'm not a fan of the 1970-01-01. I think I'd rather those be empty than "obviously wrong date." And they really weren't Created or Modified on that date by somebody, either. They were just Standard Objects that predate the org?
🎨 maybe if created and modified by/date are the same, omit the values for modified so that "real" data is more obvious?