Summary

Three problems prevented v2 from reading a stream where the same array is
stored in two fields:

• _do_array() gave a handle to the array but never stored it, so any
  reference to that array failed with Invalid reference handle. This is
  what the handles "spaced out by 2" in the report come from: the numbers
  were given to the arrays, but nothing was kept for them.
• _read_field_value() read a TC_REFERENCE found in an array field with
  _do_classdesc(), which requires a class description and rejected the
  array with Referenced object is not a class description.
• Class descriptions were stored only after their annotations and their
  super class had been read, so nothing read in between could refer to them.
  They are now stored as soon as they are created, as v3 already does.

The first two are what the reported file hits; the last one is the same kind
of problem, found while comparing with v3, and is fixed for consistency.

With those, v2 reads the 2.2 MB session attached to the issue completely.

Test plan

• New testSharedArray.ser fixture, and SharedArrayExample.java
  documenting how it is built: a byte array and a string array, each stored
  in two fields, followed by an int field which detects a desynchronized
  stream.
• Checked that the fixture reproduces the reported error before the fix
  (Invalid reference handle: 7e0005) and passes after it.
• test_shared_array added to the v2 and v3 test suites: both check the
  values, that the two fields give the very same array, and the field
  written after them.
• Checked on the session file attached to the issue: it now parses.

Fixes #62