areaEl static return for discussion

[btopro]

This is primarily for feedback / discussion. Our team has found an interesting design paradigm where our render function @heyMP and @nikkimk would have better specific examples but this pr takes an element that's critical to foot-note working visually yet abstracts it to it's own function to supply the dom node.

While looking the same in what's created for foot-note consider the following example...

import { FootNote } from 'web-components/foot-note/src/foot-note.js';

class MyFootNote extends FootNote {
  constructor() {
    super();
    // some defaults changed
  }
  static get areaEl() {
		const area = document.getElementById('#someexample');
		area.classList.add('area');
		area.setAttribute('part','area');
		area.setAttribute('role','doc-footnote');
		area.setAttribute('aria-hidden','true');
		return area;
  }
}

While not a perfect example, this would open the door for developers to extend this element, leverage it's accessibility capabilities, while supplying it's own container. For example if our apps have their OWN "foot note visual area" or maybe a consistent pop up / pop over, it would open the door toward leveraging all the internals of your element while supplying our own manner of visualization. This is a need our team has discussed (haxtheweb/issues#280) and has also envisioned potentially as footnote number, click and have it presented in context using a tool tip style presentation.

A PR / template function broken out like this could allow something like that. Opening as Draft as it's mostly conversational / feedback but if you decide to enhance via something like this approach, cool :)

[RolandDreger]

I will have a look at it in the next few days when there is more time and also take a closer look at your components.