asn1: Bare template sup. for SET{...} types

The regular ASN.1 compiler does NOT sort SET { ... } types' members by
tag, though it should.  It cannot because if a field is of an untagged
imported type, then the compiler won't know the field's tag because the
compiler does not read and parse IMPORTed modules.  At least the regular
ASN.1 compiler does handle out-of-order encodings on decode.

The template ASN.1 compiler did not even support SET { ... } types at
all.  With this commit the template ASN.1 compiler does, but still it
does not sort members on encode, and it does not decode out-of-
[definition-]order encodings.

A proper fix to these issues will require run-time sorting of SET
members on encode.  An even better fix will require making the compiler
able to read and parse more than one module in one run, that way it can
know all the things about IMPORTed types that it currently leaves to
run-time.

lib/asn1/check-gen.c

@@ -1893,8 +1893,17 @@ test_x690sample(void)
 {
     /*
      * Taken from X.690, Appendix A, though sadly it's not specified whether
-     * it's in BER, DER, or CER, but it turns out to be DER since, as you can
-     * see below, we re-encode and get the same encoding back.
+     * it's in BER, DER, or CER, but it is clearly BER and neither DER nor CER
+     * because the tags of the members of the X690SamplePersonnelRecord type
+     * are not canonically sorted in the given sample.
+     *
+     * Our compiler does NOT canonically sort the members of SET { ... } types
+     * so it produces the same encoding after decoding this test vector.  That
+     * is clearly a bug given that we aim to output DER.
+     *
+     * The template compiler doesn't even decode SET { ... } values properly
+     * when their members are not in the same order as defined (but the regular
+     * compiler does).
      */
     X690SamplePersonnelRecord r;
     heim_octet_string os;