WIP: Enable adding strongly typed format view defintion with Update-FormatData

[Jawz84]

PR Summary

Closes #7845

The Update-TypeData command offers flexibility to load type data at runtime not only through loading files, but also through providing strongly typed type data. This Pull Request aims to bring that same kind of functionality to Update-FormatData.

• Add a parameterset for adding strongly typed format view definitions to the current session. (-TypeName and -FormatViewDefinition parameters)
• Add a test for this.
• Add a parameterset for dynamically adding format view definitions (-TypeName, -ListProperties, - TableProperties, -WideProperty and -DefaultView [Table | List | Wide])
• Add a test for dynamic loading of format view definitions.
• Look into deduplicating format data entries in db.
• Add more tests.

PR Context

I wanted to format objects in PowerShell, but found out that can only be done reliably through providing a .ps1xml file.
There is no easier way. I wrote about that here: https://joskw.gitbook.io/blog/object_formatting
And I found this issue #7845, which describes the problem.

PR Checklist

• PR has a meaningful title
  • Use the present tense and imperative mood when describing your changes
• Summarized changes
• Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
• This PR is ready to merge and is not Work in Progress.
  • If the PR is work in progress, please add the prefix WIP: or [ WIP ] to the beginning of the title (the WIP bot will keep its status check at Pending while the prefix is present) and remove the prefix when the PR is ready.
• Breaking changes
  • None
  • OR
  • Experimental feature(s) needed
    • Experimental feature name(s):
• User-facing changes
  • Not Applicable
  • OR
  • Documentation needed
    • Issue filed:
• Testing - New and feature
  • N/A or can only be tested interactively
  • OR
  • Make sure you've added a new test if existing tests do not effectively test the code changed
• Tooling
  • I have considered the user experience from a tooling perspective and don't believe tooling will be impacted.
  • OR
  • I have considered the user experience from a tooling perspective and enumerated concerns in the summary. This may include:
    • Impact on PowerShell Editor Services which is used in the PowerShell extension for VSCode (which runs in a different PS Host).
    • Impact on Completions (both in the console and in editors) - one of PowerShell's most powerful features.
    • Impact on PSScriptAnalyzer (which provides linting & formatting in the editor extensions).
    • Impact on EditorSyntax (which provides syntax highlighting with in VSCode, GitHub, and many other editors).

[Jawz84]

@anmenaga Hi Andrew, can you help me get a review of the work so far, so I know if this is up to par? Thanks!

[anmenaga]

Overall this looks up to par to me. Couple of notes:

1. "WIP" must be removed from PR title (and corresponding checkbox in PR Checklist checked) before anybody will start in-depth review of the code. This is just this repo's process. "WIP" means "code changes in PR are not complete / not ready for review" therefore it does not make sense for people to spend time reviewing "WIP" PRs.
2. "Documentation needed" is checked; in addition please follow that link and file an issue (something like "Need to document new Update-FormatData parameters") in PowerShell-Docs repository that links back to this PR; and add the link to that doc issue in "Issue filed:"
3. what is meant by "Look into deduplicating format data entries in db." ?

PS. Thank you for picking up this work.

[ghost]

This pull request has been automatically marked as Review Needed because it has been there has not been any activity for 7 days.
Maintainer, please provide feedback and/or mark it as Waiting on Author

[ghost]

This pull request has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 15 days. It will be closed if no further activity occurs within 10 days of this comment.