fix cross-package and forward references in cl-protobufs

* Previously, if a field in a .proto file referenced a message in
  another proto file using a different lisp package, the cl-protobufs
  library would silently fail to serialize the field.  A similar
  problem would occur if a message defined later in the file used the
  lisp_name option to override the name generated by cl-protobufs.
  This change fixes these issues and others.
* Add conditions that are signaled when encountering an undefined
  type.
* Delay assigning lisp classes/types to fields and methods until all
  possible forward references have been parsed.
   * This allows the class slot to be unbound, so check for that case
     in print-object methods.
   * Add a test for forward references to messages that override the
     lisp name.
   * Add a test for references to messages and enums defined in
     another proto file with a different lisp package.
   * Change color-wheel-stability test, because it used "string" as
     the input type for an rpc, which seems to be disallowed (although
     I haven't found this documented anywhere).
* Signal errors during parsing for undefined types.
   * Add a test for these errors.  Add assert-error macro to qtest.
* Signal a condition if we are unable to find the definition for a
  field's type during serialization, deserialization, determining an
  object's serialized size, printing text format, parsing text format,
  or generating code for one of the above.
* Remove logic in find-qualified-name that indirects through lisp
  packages.  Proto packages and lisp packages do not necessarily map
  1-to-1.
* Always use the schema's lisp package for any symbols generated when
  parsing proto files.
* When generating lisp code using write-schema-as, set the package to
  the package used in the generated file, so that ~s will print the
  package prefix in the correct circumstances.
* Remove broken proto1 "streams" parsing ("returns" comes before
  "streams" in every example I've found); replace with proto2 syntax.
* In process-imports, the call to find-schema using a pathname was not
  giving the expected result.  Sidestep this issue by using the same
  logic to find the schema as is used earlier in the function.