Behaviour of BamHeader copy constructor

[Peter]

BamHeader does not own its underlying data but is only valid as long as corresponding BamFile is open. Is this the desired behaviour or do we wanna make the BamHeader more independent. There is a function bam_header_dup in sam.c that could be used to create an independent header*.

See docs added in r3158

Changing the behaviour is not a problem in terms of compatibility as the change would only add behaviour for code that in yat0.11 is undefined - and since a BamHeader is read only making them independent (hard copy) has no effect in terms of: "hey I changed the header and that used to effect all copies of it".

The pro with the change is obvious. You can kill the BamFile and still have a valid header object (just had a segfault due to current [undefined] behaviour). The con is that it makes the code more complicated. How is the assignment implemented? Can all instances own their data. Probably yes, except the original one that is held privately in InBamFile. That one is destructed by samclose in BamFile destructor. Is it confusing to have ownership sometimes and sometimes not, or is it OK in this case since the non-owner case is private?

[Peter]

bam_header_dup is not included in API but only declared in source files, which makes the change suggested in description impossible to implemented (in a sensible way).