Should RegularTableElement be explicitly marked as `final`?

Currently it is possible for a 3rd party library to subclass `RegularTableElement` (the class backing our `regular-table` custom element), though it is a bit awkward:

```javascript
import "regular-table";

customElements.whenDefined('regular-table').then(() => {
const RegularTableElement = customElements.get('regular-table');

class RegularFooElement extends RegularTableElement {
...
}

customElements.define('regular-foo', RegularFooElement);
});
```

We should either:

1. Make this way easier by `export`-ing `RegularTableElement` at the top level of the `regular-table` module. We should then also add a short guide to the docs about subclassing `RegularTableElement` and using it to create new custom elements (and also maybe some warnings about not calling `new RegularTableElement` directly).

2. @texodus Are there good reasons why `RegularTableElement` should be treated as `final` (ie not subclass-able)? If so, we should explicitly and loudly declare `RegularTableElement` to be final in the docs (and also explain why), and possibly also mark it as such in the code. I know there's no standard way to mark code as `final` in js, but there seem to be at least a few [workable methods](https://github.com/tc39/proposal-decorators#frozen).

I'm leaning towards 1. I've been playing around all day with subclassing and otherwise extending 'regular-table', and it seems to work pretty good. So far the only hiccup I've run into is that any styling with a selector for the `'regular-table'` tag (such as most of the styling in [`material.less`](https://github.com/jpmorganchase/regular-table/blob/master/src/less/material.less)) won't apply to subclassed custom elements, since the tag is different.