IE, open html file directly from hard disk(insead of from a http server), cssRules access is denied.
Thus an expection is thrown. But in the catch statement, another one is thrown again thus caused the whole mermaid code break.
In this line `console.warn('Invalid CSS selector "' + rule.selectorText + '"', err);` rule is undefined, so exception will be thrown if we don't check.
* Configuration are picked up from the mermaid object and is not passed as arguments. Same handling for all diagram types, sequenceDiagrams were handled in a different way before this commit.
When init is called with:
* 0 arguments - all mermaid divs are processed
* 1 argument - this is interpreted as a definition of what nodes to process
* 2 arguments - for (some) backwards compatability the second argument is interpreted as the definition of nodes to process. The first argument (prrobably a sequence config is ignored)
A definition of nodes to process can be
* a css selector for what elements to be processed
* a list of nodes as in the result of a command like the one below
```
document.querySelectorAll('.tbProcessed');
```
The existing behavior of init will always re-render the whole page, and requires that a chart be classed `mermaid`.
This change allows the user to specify:
- a DOM Node (as from getQuerySelector)
- a DOM NodeList (as from getQuerySelectorAll)
- an array of nodes (as from jQuery.find)
- a string (to be handed to getQuerySelectorAll)
The current behavior is unexpected when re-running `init()`, as every run through will start with the first `.mermaid` it finds, and start re-indexing at 0, irrespective if the original `id=mermaidChart0` is still around.
This change ensures that successive runs will not clobber old ones.
