docs(guides): update doc for automated rule creation

guides/_subsections/create-an-automated-rule.md

@@ -58,11 +58,12 @@ Previously, if we wanted to enable always-on `Continuous` monitoring using **JDK
     <details>
         <summary>Create your <code>Match Expression</code></summary>
         <p>
-            The <code>Match Expression</code> in a rule definition is a Java-like snippet of code that <b>Cryostat</b> interprets and uses to determine if a rule should be applied to any given <code>target</code>. <code>Match Expressions</code> should thus evaluate to a <code>boolean</code> value. The simplest <code>Match Expressions</code> would be the <code>booleans</code> true or false; if we use true, the rule will apply to every <code>target</code>. The <code>Expression</code> has a <code>target</code> object in global scope, with the following form in <code>JSON</code> notation:
+            The <code>Match Expression</code> in a rule definition is a <code><a href="https://cel.dev/">Common Expression Language</a></code> expression that <b>Cryostat</b> interprets and uses to determine if a rule should be applied to any given <code>target</code>. <code>Match Expressions</code> should thus evaluate to a <code>boolean</code> value. The simplest <code>Match Expressions</code> would be the <code>booleans</code> true or false; if we use true, the rule will apply to every <code>target</code>. The <code>Expression</code> has a <code>target</code> object in global scope, with the following form in <code>JSON</code> notation:
         </p>
         <figure>
 {% highlight json %}
 {
+  "jvmId": "abcd1234",
   "alias": "myAppAlias",
   "connectUrl": "service:jmx:rmi:///jndi/rmi://cryostat:9091/jmxrmi",
   "labels": {
@@ -82,28 +83,28 @@ Previously, if we wanted to enable always-on `Continuous` monitoring using **JDK
 {% endhighlight %}
         </figure>
         <p>
-          The <i>Alias, connectUrl, labels, annotations.platform,</i> and <i>annotations.cryostat</i> properties are all guaranteed to be present on the <code>target</code> object. <i>alias</i> and <i>connectUrl</i> will be non-empty strings. The <i>labels</i> and <i>platform annotations</i> may be empty—in <b>OpenShift</b> or <b>Kubernetes</b>, these are populated from the labels and annotations applied to the <code>target’s</code> pod, if any. The <b>Cryostat</b> annotations map will vary per platform, but on <b>OpenShift</b> or <b>Kubernetes</b> you can expect the <i>HOST, PORT, NAMESPACE,</i> and <i>POD_NAME</i> keys to be present and non-empty.
+          The <i>alias, connectUrl, labels, annotations.platform,</i> and <i>annotations.cryostat</i> properties are all guaranteed to be present on the <code>target</code> object. <i>alias</i> and <i>connectUrl</i> will be non-empty strings. The <i>jvmId</i> is a hash string computed by Cryostat after it successfully connects to a <code>target</code> <b>JVM</b> and is used to uniquely identify that <b>JVM</b> instance - it will be empty if <b>Cryostat</b> has not yet connected to that <code>target</code> (for example, if its <a href="#add-a-trusted-certificate"><code>SSL/TLS</code> certificate is not trusted</a> or if <a href="#store-credentials"><b>Cryostat</b> is missing the required credentials</a>) The <i>labels</i> and <i>platform annotations</i> may be empty — in <b>OpenShift</b> or <b>Kubernetes</b>, these are populated from the labels and annotations applied to the <code>target</code>’s pod, if any. The <b>Cryostat</b> annotations map will vary per platform, but on <b>OpenShift</b> or <b>Kubernetes</b> you can expect the <i>HOST, PORT, NAMESPACE,</i> and <i>POD_NAME</i> keys to be present and non-empty. Take care to use the `has` or `in` operators when dealing with the <i>labels</i> and <i>annotations</i> map structures where specific keys may not exist.
 
           Here are some examples of <code>Match Expressions</code>:
         </p>
         <figure>
 
 {% highlight bash %}
-target.alias == ’com.example.MainClass’
+target.alias == 'com.example.MainClass'
 
-target.alias == ’myAlias’
+target.alias == 'myAlias'
 
-target.labels[‘com.example/service’] == ’customer-login’
+'com.example/service' in target.labels && target.labels[‘com.example/service’] == 'customer-login'
 
-target.labels[‘com.example/service’] != ’customer-login’
+'com.example/service' in target.labels && target.labels[‘com.example/service’] != 'customer-login'
 
-target.annotations.cryostat.PORT > 3000
+has(target.annotations.cryostat.PORT) && target.annotations.cryostat.PORT > 3000
 
-target.annotations.cryostat.PORT > 3000 && target.annotations.platform[‘io.kubernetes/annotation’] == ‘enabled’
+has(target.annotations.cryostat.PORT) && 'io.kubernetes/annotation' in target.annotations.platform && target.annotations.cryostat.PORT > 3000 && target.annotations.platform['io.kubernetes/annotation'] == 'enabled'
 
-!!target.annotations.platform[‘io.kubernetes/annotation’]
+!('io.kubernetes/annotation' in target.annotations.platform)
 
-/^customer-login[0-9]\*$/.test(target.alias)
+target.alias.matches("^customer-login[0-9]\*$")
 {% endhighlight %}
 
 </figure>
@@ -177,7 +178,7 @@ We can define a rule that applies to any `target` application that has platform-
 {
   "name": "k8sMonitoring",
   "description": "Enable the Demo template on any target with the jfrMonitoring=true annotation",
-  "matchExpression": "target.annotations.platform[‘jfrMonitoring’]==’enabled’",
+  "matchExpression": "'jfrMonitoring' in target.annotations.platform && target.annotations.platform['jfrMonitoring']=='enabled'",
   "eventSpecifier": "template=Demo,type=CUSTOM",
   "archivalPeriodSeconds": 300,
   "preservedArchives": 12