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.