fix: primitive metadata values cannot be loaded in jsii languages (#121)

In aws/aws-cdk#31041, the CDK started emitting booleans and numbers as metadata values. 
However, since these types are not officially declared in the schema, jsii runtime type checking prevents loading them:

```console
[ERROR] ├── 🛑 Failing value is a boolean
[ERROR] │      true
[ERROR] ╰── 🔍 Failure reason(s):
[ERROR]     ├─ [as string] Value is not a string
[ERROR]     ├─ [as array<aws-cdk-lib.cloud_assembly_schema.Tag>] Value is not an array
[ERROR]     ├─ [as aws-cdk-lib.cloud_assembly_schema.FileAssetMetadataEntry] Value is not an object
[ERROR]     ╰─ [as aws-cdk-lib.cloud_assembly_schema.ContainerImageAssetMetadataEntry] Value is not an object
```

Fixes aws/jsii#4742

> Note that releasing this will immediately resolve the above issue, no cdk release needed. It does bump the schema version, which we can update at will.

## FAQ

### If the types are not allowed in the schema, how can a manifest with them be written?

Actually, these types **are** allowed in the schema, in the json schema that is:

https://github.com/cdklabs/cloud-assembly-schema/blob/f5ae537437531364646e7515e5286e21583c8421/schema/cloud-assembly.schema.json#L131-L133

This free form data is added to the json schema in order to support calls to `node.addMetadata(key: string, value: any)`, as defined in the `constructs` API. However, this type was intentionally left out of the type declaration:

https://github.com/cdklabs/cloud-assembly-schema/blob/f5ae537437531364646e7515e5286e21583c8421/projenrc/update-schema.ts#L79-L89

I'm fairly certain the comment is not applicable anymore, because we don't run jsii compatibility checks on the schema (we just bump it on every change). In practice, I think we can probably get rid of this patching and just type metadata entry values as `any` - but that seems like a bigger change I don't want to go into right now. 

### If such manifests cannot be loaded, how does synth work?

Because during synth, loading the assembly using the `Manifest` class happens solely inside the javascript space, it doesn't callback to java land. This problem presents itself **only when** directly using the java `Manifest` class and invoking the `loadAssemblyManifest` function on a manifest produced by `app.synth()`.

lib/cloud-assembly/metadata-schema.ts

@@ -260,14 +260,24 @@ export type LogicalIdMetadataEntry = string;
  */
 export type StackTagsMetadataEntry = Tag[];
 
+/**
+ * Any other type of metadata entry
+ *
+ * This could probably be changed to `any`, but it's safer not
+ * to do so right now.
+ * See https://github.com/cdklabs/cloud-assembly-schema/pull/121.
+ */
+export type PrimitiveType = boolean | number | string;
+
 /**
  * Union type for all metadata entries that might exist in the manifest.
  */
 export type MetadataEntryData =
   | AssetMetadataEntry
   | LogMessageMetadataEntry
   | LogicalIdMetadataEntry
-  | StackTagsMetadataEntry;
+  | StackTagsMetadataEntry
+  | PrimitiveType;
 
 /**
  * Type of artifact metadata entry.

schema/cloud-assembly.schema.json

@@ -126,7 +126,11 @@
                             }
                         },
                         {
-                            "type": "string"
+                            "type": [
+                                "string",
+                                "number",
+                                "boolean"
+                            ]
                         },
                         {
                             "description": "Free form data."

schema/version.json

@@ -1,4 +1,4 @@
 {
-  "schemaHash": "f0ccc3212331af8a1c75830878d218fd667e5957063831be3b5bfd803b25f0cc",
+  "schemaHash": "bf762e5da559c685e06892ef65fdfc33d1c4bd53d4eb07d4a326d476ac58ae25",
   "revision": 39
 }