Update `addStyle` and `addExclusiveStyle` Interface

Problem

Currently, style correlation methods on Analysis objects expect analyzers to pass the exact BlockObject they wish to add. This forces analyzers to look up block references and pushes a lot of standard error catching logic into the analyzers, complicating analyzer implementation.

Solution

By updating addStyle and addExclusiveStyle to accept the parent Block, and string representations of child BlockObjects to add, block lookup and error throwing can happen in css-blocks core, further simplifying analyzer implementations.

Example

addStyle(block, ".foo", true);
addExclusiveStyle(block, true, ".foo[state|bar]", ".foo[state|baz]");

Issues

Analyzers will have to translate discovered classes and attributes into well-formed selector strings. This string formatting may be unpleasant and result in a lot of boilerplate code. We may consider instead exposing a BlockObject lookup API on Blocks that will throw a helpful error if the block doesn't exist. This removed error checking from the Analyzers, but still provides them a programmatic interface for accessing and passing blocks around.

addStyle(block.getClass("foo", locInfo), true); // Will throw if "foo" is not a class on `block`
addStyle(block.getClass("foo", locInfo).getState("bar"), true); // Will throw if "foo[state|bar]" does not exist on `block`

Start by locating the Analysis methods addStyle and addExclusiveStyle and the Block lookup APIs described in the issue. Review how analyzers currently pass BlockObjects and handle lookup errors, then decide which proposed interface is appropriate. Done means the selected interface is implemented in css-blocks core and analyzer usage no longer requires duplicated lookup or error-handling logic.