ManagedReferenceDocumentProcessor fails with exception when a custom IPostProcessor is active and documentation contains characters like &, ' or "

**Operating System**: (`Windows` or `Linux` or `MacOS`)

Windows 10

**DocFX Version Used**:

2.58.9

**Template used**: (`default` or `statictoc` or contain custom template)

Custom template with a custom processor in the plugins directory

**Steps to Reproduce**:

1. Have C# code that has one of the following characters in their documentation: &, " or ' (might also affect other characters)
```csharp
/// Quotes are "bad".
public string MyProperty { get; set; }
```
2. Have a custom processor
3. Have a DocFx project that generates a documentation from the C# code and runs the custom processor
4. Try to build the documentation

You can use the attached sample project for reproduction.
[MySampleLibrary.zip](https://github.com/dotnet/docfx/files/7661667/MySampleLibrary.zip)

**Expected Behavior**:

Documentation is created successfully.

**Actual Behavior**:

The ManagedReferenceDocumentProcessor crashes before my custom processor is executed.

```
3> Target DocBuild:
3> Target DocGenerateMetadata:
3> Executing "C:\Users\ddreibrodt\.nuget\packages\docfx.console\2.58.9\build\..\tools\docfx.exe" "C:\projects\docfxbug\MySampleLibrary\MySampleLibrary.Docs/docfx.json" -o "" -l "log.txt" --logLevel "Warning" -f
3> [21-12-06 03:11:15.333]Error:[BuildCore.Build Document.CompilePhaseHandlerWithIncremental.ManagedReferenceDocumentProcessor.Build.BuildManagedReferenceDocument](apidoc/csharp/MySampleLibrary.Class1.yml)Markup failed: Could not load file or assembly 'System.Runtime.CompilerServices.Unsafe, Version=4.0.4.1, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040).
```

**Workarounds**

- Removing the problematic characters results in successful creation of the documentation.
- Removing the processor from the template plugin directory results in succesful creation of the documentation even with the problematic characters still present.