TntIcon and docs updated.

Note about docs: We could really do with a means of variably displaying different versions of the code, maybe making use of tabs to select the language; in this case Vue, Pug and Markdown.

Ran into a bit of a roadblock trying to avoid duplication between Tnt Core and Tnt Content.

On TNT Core, we want all components to be prefixed with Tnt. On TNT Content, we want certain components to be usable without that prefix in markdown documents (:breadcrumbs rather than :tnt-breadcrumbs). This is easy enough to achieve but... we don't want to duplicate code unnecessarily.

The issue...

I've been creating component duplicates that aim to just render the actual component and pass along the props... and the slots. It's there we run into an issue. Slots are more difficult than props to pass along directly, and I've been trying to make use of Vue Render functions (h()) but these just aren't working.

Alternative solution:

The whole point of this effort was consistency. That tnt- prefix isn't actually what we want; it just seemed like the best approach. We could instead do away with it and offer up only prefix-less components. Then this duplication I'm attempting wouldn't be necessary at all; components wouldn't need to go by two separate names.

It's simpler... it's actually easier to migrate too, as well (we just look for uses of "Tnt" or "tnt-" in the consuming applications and remove the relevant instances). It sets up a cleaner foundation on which to... maybe develop on this idea more in future.

I think it sounds like the best option: scrap the prefixes, recommend against installing other libraries that might conflict with TNT.

One thing's got me returning to the idea of using the Tnt- prefix... The Button component. <button> already exists in HTML. We could call it Btn instead, but this is the opposite of what we're already having to do for Image which would conflict with the <img> element.

Simply having a prefix avoids all of these conflicts, and potential future conflicts (future-proofing is important! You never know when a new HTML element will be added which conflicts with one of our components).

So to the problems I was having with using render functions to create duplicate components... let's just not worry about that, and instead fully duplicate the components where we need to. It is annoying but... so long as we have working components, we can look to refactor them for DRY code in the future.

Cancelling this as it's tedious and not a priority. It can and will be circled back to as a later consideration late in the progress towards v1.0.