fix for Seaside31 Issue glassdb/Seaside31#21

- ByteArray>>asString was implemented pretty inefficiently but
  was not that heavily used until the encode primitive started
  returning ByteArrays (actually UTF8 instances) instead of
  Strings and I put the #asString message into the mix to convert
  the ByteArray to Strings as expected by the Seaside code
- ByteArray>>asUnicodeString is a primitive and is about as fast
  as an encode so it is likely that the performance impact of
  asUnicodeString is not anywhere near the penalty of the old
  implementation...
backup out the fix for Seaside31 Issue glassdb/Seaside31#21

- while ByteArray>>asUnicodeString is indeed much more efficient at
  converting a ByteArray to a String, it turns out that the purpose
  of the asString usage was to allow the ByteArray bytes to be
  interpretted as characters and directly inserted into strings ...
  the call was not intended to decode the UTF8 which
  ByteArray>>asUnicodeString does ...
- will need to work a little bit harder to find a fix
another proposed fix for Seaside31 Issue glassdb/Seaside31#21

- this time asString interprets the bytes in the receiver as it's
  face value ... even for Utf8 instances ...
- the code is pretty funky, because all of the normal ways of
  converting a ByteArray into a String (i.e., String
  class>>withBytes:) are not permitted with instances of Utf8, so
  I had to resort to #changeClassTo: which is not allowed to be
  sent to an object on the stack ... so a copy is made ...
- with this checkin ByteArray>>asString has the implementation for
  UTf8. A pure ByteArray can use String class>>withBytes: without
  the  #changeClassTo:, but I want to make sure that this trick
  works for all 3.x versions and that all of the tests pass ...
fix for Seaside31 Issue glassdb/Seaside31#21

- move the fancy changeClassTo: based fix to UTF8 class (which
  is only present GemStone 3.1 and 3.2)
- simplify asString for ByteArray itself (needed in GemStone 3.0)
Merge branch 'issue_21_utf8'