Revert a partial change introduced in #3627.

We cannot cache the cram_block pointer and use ..decode_char2() and
..decode_block2() functions to avoid looking up the block as this
breaks multi-slice containers.

The speed gains in doing this were marginal at best; 1% or so.


git-svn-id: svn://svn.code.sf.net/p/staden/code/io_lib@3687 ba6f2710-ca9f-427c-89d3-5bf716dbc8e1
Merge with trunk.


git-svn-id: svn://svn.code.sf.net/p/staden/code/io_lib@3688 ba6f2710-ca9f-427c-89d3-5bf716dbc8e1
Removed a duplicate piece of code, probably added in the previous
fix to the block-caching issue.


git-svn-id: svn://svn.code.sf.net/p/staden/code/io_lib@3689 ba6f2710-ca9f-427c-89d3-5bf716dbc8e1
Reverted r3669.

While technically correct to fill out M5 fields, it is useless and
blocks genuinely desired behaviour (ie how to produce a CRAM file when
we have no idea what the ref seq is).

I believe in v3.0 the spec will be changed to permit this behaviour.


git-svn-id: svn://svn.code.sf.net/p/staden/code/io_lib@3690 ba6f2710-ca9f-427c-89d3-5bf716dbc8e1
Added ZM:B: to the FZ:B: special block as IonTorrent uses this too.

Also bug fixed the FZ:B: encoding as it was just doing string handling
before which is incorrect for the B type.


git-svn-id: svn://svn.code.sf.net/p/staden/code/io_lib@3691 ba6f2710-ca9f-427c-89d3-5bf716dbc8e1