Add related content component

[roadlittledawn]

Closes #194

Adds a <RelatedContent /> component to all pages that do not already have a For more help section populated. If just <h2>For more help</h2> element is present without content following it, it's removed during migration so the basicDoc.js template knows to insert the default content via the <RelatedContent /> component.

This also adds a prop to MDXContainer component so RelatedContent is contained within the container to take advantage of all the CSS rules.

Example of doc that has custom For more help content pre-populated:
https://docs-preview.newrelic.com/docs/browser/new-relic-browser/page-load-timing-resources/session-tracking

[roadlittledawn]

Note to selves: I could not get turndown.remove() to work, but .addRule() did the trick. Maybe someone has insight why this wouldn't work:

.remove(
  (node) => node.nodeName === 'H2' && node.textContent === 'For more help' && !node.nextElementSibling
)```

[jerelmiller]

Had a few questions for you.

[jerelmiller]

I would avoid setting this default to an empty object. If you happen to hit this use case, React will complain about trying to render objects.

[jerelmiller]

I'm a bit mixed on this approach. While this solves the issue of making sure the content shows up in the correct container with the correct styles applied, this doesn't allow us any customization on the "extra" UI that is no longer markdown. Any additional UI that we want to add for any template would need its own prop.

What about potentially creating a body prop for the MDX body content and instead reserving children for this use case? This gives us a pretty good way to customize this component with extra UI without needing to open up new props every time we need to do so. This might look like this in practice:

import MDXContainer from './MDXContainer'

// ...
// Body with no additional UI
<MDXContainer body={body} />

// Body with additional UI
<MDXContainer body={body}>
  {moreHelpExists ? null : <RelatedContent />}
</MDXContainer>

This means that the MDXContainer doesn't have to care about the type of component that is rendered underneath the markdown. Thoughts?

[roadlittledawn]

i see what you're saying. makes sense to me. i like that extra flexibility in putting any additional stuff in children. doing that now.

one question about that. would would the PropType be for children then? would it still be children: PropTypes.node

[jerelmiller]

Yep! PropTypes.node works great!

[jerelmiller]

🎉

[jerelmiller]

[nit] Would it make sense to pull the For more help out to a constant at the top of the file so that its easy to reference/tweak?

[jerelmiller]

Very odd that would't work. Thats ok. addRule works fine for me!