Tag option parsing flaws

[Dijky]

While working on #33 I noticed some inconsistencies in ending a tag option and proceeding to the next one:

• in OPTION_STATE_VALUE, a trailing space is mandatory to detect the end of the value
• in OPTION_STATE_QUOTED_VALUE, a peek-ahead is done to make sure a space (or end of tag content) comes next. If there is any other character, a ParserException is thrown and caught and all options will be interpreted as one.
• in OPTION_STATE_JAVASCRIPT however, there is no such check.
  A tag like [video js=javascript: ok();x=y] is considered valid.

I can make a pull request once #33 has been decided, so the merges will not conflict.

I would also like to add single-quoted values ([tag opt='use " in here without problem']) and possibly backslash-escaping ([tag opt="this: \" is a double quote"]).

Another problem is using ] in a (quoted) tag option. Due to the current parser implementation this is impossible.
After all, the parser is not a complete DFSM since the tokenizer only knows [, ], and everything else as tokens.

[shmax]

@Dijky, how are you coming on this?