Adaptions to new features in VexFlow, minor patches and additions

With these changes, MEItoVexFlow seems to basically work with the latest version of VexFlow. Most of the tests pass; some others fail -- I'm not totally sure, but I think that should not be due to the recent MEItoVexFlow changes. Could you check if there's any unexpected rendering of the test cases? 
The Prokofiev and Isaac tests fail, because they require support for namespace prefixes, which is not handled by the script yet. Can jQuery handle namespace prefixes at all (in a way other than 'find score or mei:score')? Obviously, everything would work if we replaced all jQuery.find()s etc. by getElementByTagNameNS. Do you think this would be a good solution or do you have other plans (for example, transform the MEI files before sending them to MEItoVexFlow)?
Since MEItoVexFlow has an autostem feature now, I commented out the stem calculation in MEItoVexFlow and let VexFlow handle this in all cases when stem directions are not specified in the MEI code.
At the start of meitovexflow.js, I supplied changes to VexFlow (support for the 8va treble clef) -- I noticed, that you already use these clefs in MEIView, so I commented it out again.
I also added support for different bar line types, based on Raffaele's experimental branch. There are still open questions: Right now, MEItoVexFlow detects them in extract_layers and passes them as function parameters to initialise_staff_n. Do you think this is a good solution or would you prefer to write it to the staff info array instead? I think, using the staff info array could address one issue: The staff lines are currently rendered in an additive manner: When you have 2 measures, the first with no bar line specified, the second with @left="invis", there will be a bar line in the middle, because the default right bar line will be shown; I would expect the measure line to be invisible, because @left="invis" should win over the default line. On the other hand, the usage of @left is not encouraged in the MEI guidelines. It could be OK to postpone addressing this issue. My main reason for handling @left is that i'd like to be able to have no line at all at the beginning of a system. I'm not too content with my solution, maybe you have a better idea. Right now, when you want a staff to have no line on the left, you have to both specify measure/@left="invis" and staffGrp/@symbol="none". Having to do two thing to get one result is not intuitive. The obvious reason for this is that the leftmost line is actually rendered twice: Once as a staff symbol, once as the default bar line of the first measure. 
A clean solution could be to by default not render the left bar line of a measure when it's the first measure in a staff system (in this case, only the staff line will be shown). I haven't checked yet if this has side effect. Do you generally think this could be a solution?