Simplify Ignite by eliminating BlockHTML

[JPToroDev]

While revisiting the nuts and bolts of Ignite during the recent testing initiative, I noticed that BlockHTML is put to use substantively in only two places:

1. The contents closure of Item uses @BlockHTMLBuilder to set an accordion item’s body.
2. Inside the render() method of Grid, we cast to BlockHTML to extract the columnWidth information.

But here’s the thing:

1. Neither HTML nor Bootstrap require an accordion's body to be a block element, making this an unnecessary restriction.
2. The HTML variant checking in Grid is faulty. Custom HTML elements are wrapped in <div>, but because they only conform to HTML, not BlockHTML, they aren’t handled correctly. What’s more, inline elements should not be ignored in the rendering process—as they currently are. Instead, they should be treated the same way as block elements.

Before CSS controlled an HTML element’s display value, elements fell into two main categories—those with a block default, and those with an inline default.

We can eliminate all of the above problems by axing BlockHTML, moving columnWidth to CoreAttributes, and treating HTML elements as block elements by default—with InlineHTML working to restrict/specialize that default behavior.

This also allows us to eliminate a bunch of repetitive modifier extensions from the codebase.

This may also allow us to simplify #297.

[twostraws]

My original hope here was to make invalid HTML impossible. While that has caused some problems – I dislike having to place images inside text, for example – it at least attempts to follow the standards. Does that remain true here?

[JPToroDev]

Yes, that goal remains true here thanks to InlineHTML, which we cannot remove. InlineHTML is the key to HTML safety, not BlockHTML, which is actually laying the groundwork for future problems.

[JPToroDev]

It is worth noting that adding string interpolatability to every HTML element threatens that goal though.