fix unpacking in sint24() method

- both tuple unpacking and [0] indexing were used on the single
  integer value being unpacked, resulting in a runtime error
  Resolves issue #19
fix typo when formatting bigint defaults

- This bug was introduced when addressing issue #11 and the
  fix is a trivial change from vaue -> value.
  Resolves issue #20
simply handler_options management

- handler_options bit flags are now always stored in TableOptions.
  checksum, delay_key_write, pack_keys, and stats_persistent flags
  are now derived properties on the TableOptions instance that
  compute their values based on handler_options
- This change was made to allow other stages of frm processing
  to access the handler options.
tweak default processing for blob types

- largely reverts the change made as part of issue #9
- allows blob fields to consume a null bit - if the column is
  nullable
- the default value for blobs is now suppressed after null bit
  processing, so ensure null_bit offset is incremented as
  appropriate
initialize null bit based on HA_OPTION_PACK_RECORD handler flag

- previously this was incorrectly set to '1' in all cases. This
  is only correct when dealing with tables that do not have the
  PACK_RECORD flag set. For those tables, the null position should
  start at 0.
  Resolves issue #21
Merge branch 'feature/issue#21' into develop
unpack signed 24-bit integers correctly

- previously pad was always 0 and dubious logic of inverting a
  python integer was done. Now the most significant byte is
  checked and the pad adjusted according to the sign.  Then
  a straightforward unpacking of a signed 32-bit integer composed
  from the 24-bit value + padding is performed according to the
  desired endian behavior
  Resolves issue #23
adjust formatting for float/double defaults

- previously this used the naive str(value) in python, but now
  explicit precision is specified to better match mysql formatting
  behavior for these data types
  Resolves issue #22
tweak table comment output to better match mysql behavior

- frm-to-schema now outputs COMMENT='<value>' rather than
  COMMENT '<value>'.  Both are syntactically valid, but using an
  equal separator makes it much easier for automated tests to
  verify frm-to-schema output.
  Resolves issue #24