Recommend versioning script instead of using configmap 📝

When discussing some potential ways a Task could be compromised,
@afrittoli mentioned that if a Task refers to some remote source for a
script, there is the potential for that source to be modified and run
something malicious inside a Task. As he described this, he mentioned
that our catalog recommends putting scripts into configmaps, which I was
surprised to see. A script inside a configmap does have this potential
attack vector (though you'd have to have write access to the configmap
to pull it off) but I'm actually a bit more concerned that this isn't
a great solution for maintaining scripts over time. Not to mention that
I'm not how we would support this in the catalog (we'd have to start
supporting applying and versioning ConfigMaps alongside the Tasks that
reference them).

So this commit changes the recommendation to recommend 'graduating'
large scripts from script to tools and treating them like you'd treat
other code. This is still not a fantastic solution as it requires you to
maintain and publish your own images but I think it's a step in the
right direction (and if it helps, I could also see a world where we
support storing and publishing those images via the catalog as well -
though I'm pretty sure @vdemeester disagrees with me here).

recommendations.md

@@ -174,49 +174,22 @@ maintain it in-line.  Because you have already avoided interpolation
 in the script, there is no real need for the script to be in-lined
 into the Task.
 
-Use a ConfigMap for your script, and mount the configmap in the task.
-Use a single _command:_ that executes your script (optionally with
-environment variables and with parameters):
+As with all configuration and code that you write as part of software
+development, it is important to treat the Tasks and embedded scripts
+with the same care you use for your other code.
 
+Scripts should be maintained such that they can be versioned and tested;
+therefore as a script grows beyond a few simple lines, you should store
+the script in version control, and use tests and code review to maintain
+it over time. At this point you may want to consider switching from a
+language which does not naturally support tasking, such as bash, to one
+that does, such as Python.
 
-```
-  volumes:
-  - name: scripts
-    configMap:
-      name: my-task-scripts
-      defaultMode: 0755
-  steps:
-  - name: foo
-    image: myimage
-    volumeMounts:
-    - name: scripts
-      mountPath: /mnt/scripts
-    volume
-    command:
-    - /mnt/scripts/my-command.sh
-```
-
-This allows you to create and update your configmap from a real
-script.  An external script-file allows you to edit it stand-alone as
-a proper script file, rather than in-lined into a tekton task yaml
-file.  This gives you better completion, syntax checking, and many
-other benefits.  You can even run the script locally.
-
-
-```
-#!/bin/bash
-# my-command.sh
-echo "${PARAM_ONE-Hello world}"
-```
-
-To create the configmap:
-
-```
-kubectl create configmap my-task-scripts --from-file=my-command.sh
-```
-
-For bonus points, use a kustomize generator to create your task; this
-allows you simple "kubectl apply -k".
+At this point, the best option we have to offer is to build and publish
+an image which contains your tested, versioned script, and use that image
+from within your Task. This may seem like a big ask, but another way of
+looking at it is that your script has graduated from just being a script
+to being a tool.
 
 ## Test and verify your task code