Adapt to support PDF.js v1.0.907

... as per #86.

Tested with:
 * Iceweasel 31.2.0 (Shipped with Debian, built on top of Firefox ESR) - ships with PDF.js v1.0.68
 * Firefox 31.3.0 (current ESR a.k.a. Extended Support Release) - ships with PDF.js v1.0.68
 * Firefox 34.0.5 (current stable) - ships with PDF.js v1.0.712
 * Firefox 34.0.5 (current beta - yes, it's the same as stable, just released) - ships with PDF.js v1.0.712
 * Firefox 35.0a2 (developer edition a.k.a. aurora a.k.a. alpha) - ships with PDF.js v1.0.907

According to tests, all involved PDF.js versions are now fully supported.

> Well, then it seems to me they aren't all "view fields" if some of them are now on the application and some are on the view.

Obviously, the PDF.js guys refactored their code, so yes, now we can (retroactively) classify those fields into two different categories, if we really want to.

> Maybe you could do the version sniffing and then set references to the application and the view. In PDFjs < v1.0.712 they would both be the PDFView object, but in newer versions they would be different objects and your code would be a lot more readable. You probably also wouldn't need your get and set helper functions, and you could use dot attribute access instead of string object indexing.

Yes, we could do that, but there is no way to know if that would be reliable for all versions.
I am testing at 3 (easily accessible) PDF.js versions, but there are several interim released versions,
and then the bleeding edge is different yet again.

If we simply *assume* that a given field will be at a given location, based on some complicated logic using the version string, we are simply asking for trouble. Simply *detecting* that the field is there is way more resilient and reliable.