Update scripts/security docs for sandboxed world (#23977)

Drops any mention of non-sandboxed scripting languages other than a
brief "we don't support them and we shouldn't because A and B"
statement.

Relates to #23930

docs/reference/modules/scripting/security.asciidoc

@@ -51,12 +51,11 @@ Bad:
 [[modules-scripting-security-do-no-weaken]]
 === Do not weaken script security settings
 By default Elasticsearch will run inline, stored, and filesystem scripts for
-sandboxed languages, namely the scripting language Painless, the template
+the builtin languages, namely the scripting language Painless, the template
 language Mustache, and the expression language Expressions. These *ought* to be
 safe to expose to trusted users and to your application servers because they
-have strong security sandboxes. By default Elasticsearch will only run
-filesystem scripts for non-sandboxed languages and enabling them is a poor
-choice because:
+have strong security sandboxes. The Elasticsearch committers do not support any
+non-sandboxed scripting languages and using any would be a poor choice because:
 1. This drops a layer of security, leaving only Elasticsearch's builtin
 <<modules-scripting-other-layers, security layers>>.
 2. Non-sandboxed scripts have unchecked access to Elasticsearch's internals and
@@ -130,8 +129,8 @@ in the following form: `${pluginName}_${operation}`.
 
 The following example disables scripting for `update` and `plugin` operations,
 regardless of the script source or language. Scripts can still be executed
-from sandboxed languages as part of `aggregations`, `search` and plugins
-execution though, as the above defaults still get applied.
+as part of `aggregations`, `search` and plugins execution though, as the above
+defaults still get applied.
 
 [source,yaml]
 -----------------------------------