VCFHeader class design is unsafe

[droazen]

The current version of the VCFHeader class maintains a master list of header lines (mMetaData) plus type-specific lookup tables for each kind of header line. This design is unsafe and a source of bugs (we've already seen one!), as the various views into the header data are prone to getting out of sync, and the various accessor methods are not consistent in the views they access (some rely on the master list of header lines, some on the type-specific tables).

We should refactor this so that each header line is only stored in one place. Since one of the operations we need to support is getMetaDataInInputOrder() we can't just use the type-specific maps, but we could get rid of the maps and just store everything in mMetaData. This would come at a performance cost when accessing header lines by key or by type, but would improve safety and simplify the code a great deal. Since header operations typically scale by the number of files rather than the number of records, performance should not trump safety in this case.

[james-d]

Just a comment: implementations of the type-specific (and key-based) accessor methods (getContigLines(), etc) will be substantially cleaner (and potentially quicker) using Java 8 API. Since it is relatively close (< 5 months) to the projected end of support for Java 7 in this project, perhaps it makes sense to wait until then to change the implementation.

[lbergelson]

Everything will be better once java 8 is here!