Add a new conceptual help topic to cover the ETS (Extended Type System) systematically and comprehensively

Start with the existing about_Types.ps1xml article and the proposed about_Types_Extended topic. Cover the ETS concepts, member definitions and detection, type-name changes, precedence, and .NET interaction described in the issue, then add the new topic to the documentation TOC and link the related article.

Summary of the new document or enhancement

As a user, I want to know:

• how PowerShell itself decorates .NET types with additional properties (members), both at the type level (as PowerShell does with the built-in type data) and at the instance level (as PowerShell's provider cmdlets do, e.g. Get-Content).

  • In addition to adding arbitrary new members, so-called extended members - the engine itself also provides so-called adapted members at the type level, for select types (e.g., [xml], WMI/CMI classes, COM classes, and dictionaries (hashtables)). Adapted members surface entities from different object frameworks as if they were regular .NET type members, for simplicity and unified access. (A simple example is the ability to treat the entries of a dictionary as if they were properties; e.g., @{ foo = 1 }.foo, as an alternative to @{ foo = 1 }['foo'].)
    Note that it looks like the AD (Active Directory) provider, as an external module, uses the same technique, but I'm unclear on whether there are public APIs that would allow user code in general to do the same.

• how I can define extended members myself (Update-TypeData in-session vs. *.types.ps1xml files as part of modules, at the type level; Add-Member / .psobject.Properties.Add() at the instance level)

• that creating [pscustomobject] instances is also an application of the ETS, namely the construction of an object solely composed of ETS instance members, without any underlying .NET object.

• how I can dynamically add arbitrary ETS type names to objects (instances), for various reasons: to add members to it, to reflect the original type after deserialization (as done by PowerShell itself), to associate an object with formatting data (e.g.,
  @{ Name = 'NotReallyAType'; IsPublic=$false; PSTypeName = 'System.RunTimeType' } or
  ($o = [pscustomobject] @{ foo = 'bar' }).pstypenames.Insert(0, 'CustomType'))

• what type of ETS members I can define and how I can detect ETS members (Get-TypeData at the type level, Get-Member -Type AliasProperty, CodeProperty, NoteProperty, ScriptProperty, ScriptMethod, CodeMethod (others?) at both the type and the instance level)

• how precedence is resolved between ETS members and .NET native members of the same name (ETS instance members shadow ETS type members, which in turn shadow native members).

• that ETS members are PowerShell-specific and aren't visible to .NET methods (but instance members are preserved when they pass through .NET APIs)

about_Types.ps1xml partially covers this, but is primarily focused on creating persistent ETS additions via *.types.ps1xml files.

Details of requested document:

• Proposed title: about_Types_Extended
• Propose location in the TOC:
• Target audience: users
• Purpose or scenario:
  or
  Proposed changes/additions to existing article:
• List of related articles to link to: about_Types.ps1xml