Update api-documenter to surface information about protected members and fix <p> rendering bug

[zelliott]

To fix the <p></p> bug...

This PR introduces the concept of a "queued write" to the IntendedWriter that allows us to "queue" writes for subsequent write calls. It's a WIP and I wanted to get some early thoughts before diving in deeper and cleaning up the API a bit.

Some alternatives include:

• Add a post-processing step after CustomMarkdownEmitter has finished that "strips" useless text substrings like <p></p>. I didn't take this approach because I wasn't sure how to distinguish between human-authored <p></p> text in a doc comment and <p></p> generated by the emitter.
• Extend IntendedWriter and StringBuilder to allow for "removing" messages from the string being built-up. Then, right before writing a </p>, we can check to see if the last written chunk was a <p>, and if so, remove the <p> and avoid writing a </p>.
• Traverse the trimmedParagraph.nodes before writing any <p> tag in order to determine whether anything will be written. Create a helper function called something like willWriteAnything that can be called on a list of nodes. We can also place this function right at the top of writeNodes to quickly return out if we know nothing will be written. Note however that as the recursive writeNode function changes, this helper function will potentially need to change as well. Suppose writeNode is updated such that LinkTag no longer writes anything. The helper function will also need to be updated.
• Add a new dryRun boolean option to writeNodes that allows us to call writeNodes without actually writing anything. Instead, it returns a string of what would have been written. We can then check to see if this is empty, and if so, not write a <p>. If it's not empty, we can take the string we would've written and write it immediately after the <p>. If this option can work, I think I potentially like this the most. I just only came up with it recently.

[zelliott]

Closed in favor of microsoft#3483.