[Tokenizer] move if context to methods allowing .write to be optimized

This fixes the critical issue in #60 so `Tokenizer.write` can eventually be optimized.

---

#### Before this patch: 
**htmlparser2 benchmark**
```
Test self_closing took 5.253333333333333
Test tag took 12.226666666666667
Test comment took 3.7866666666666666
Test directive took 1.5533333333333332
Test special took 10.826666666666666
Test xml took 16.84
```

**article htmlparser2 benchmark**
```
11.2396 ms ± 8.15249
```

#### After this patch:

**htmlparser2 benchmark**
```
Test self_closing took 5.593333333333334
Test tag took 12.773333333333333
Test comment took 3.8733333333333335
Test directive took 1.5066666666666666
Test special took 12.4
Test xml took 19.526666666666667
```

**article htmlparser2 benchmark**
```
5.19962 ms ± 2.98707
```

During the development I have only used the article benchmark since I known that uses real-life data and I can't really figure out if an increase in _took_ is good or bad. However going from `11.2 - 12.0` to `5.0 - 5.6` [ms/file] is very good.

I also took the liberty of generating a [FlameGraph](http://jsbin.com/ehugev/1) using a [modifined Tokenizer](https://gist.github.com/AndreasMadsen/6130122) as you see quite a lot of time is spend in just `Tokenizer.write` and not the case specific methods, I don't know if this can be because of inlineling, but I assume its just the huge amount of if cases there need to be passed in each loop.

As for the remaining deoptimizing I don't think much can be done, when looking at the Hydrogen output it seams like its simply dude to some positive assumption there turns out to be false and it even happens for some 3 line methods. The only thing all this has in common (if there is a common factor) is setting the `this._state` property, which the Hydrogen output also suggest is whats getting changed.

On a side node I did try to wrap the if cases intro some master-state like `tagname, attribute, comment` to check if the many checks could be reduced and at best that didn't do any difference, maybe because this required setting one property more in many of the cases.