add LISTCONFIGS to external special remote protocol

Special remote programs that use GETCONFIG/SETCONFIG are recommended
to implement it.

The description is not yet used, but will be useful later when adding a way
to make initremote list all accepted configs.

configParser now takes a RemoteConfig parameter. Normally, that's not
needed, because configParser returns a parter, it does not parse it
itself. But, it's needed to look at externaltype and work out what
external remote program to run for LISTCONFIGS.

Note that, while externalUUID is changed to a Maybe UUID, checkExportSupported
used to use NoUUID. The code that now checks for Nothing used to behave
in some undefined way if the external program made requests that
triggered it.

Also, note that in externalSetup, once it generates external,
it parses the RemoteConfig strictly. That generates a
ParsedRemoteConfig, which is thrown away. The reason it's ok to throw
that away, is that, if the strict parse succeeded, the result must be
the same as the earlier, lenient parse.

initremote of an external special remote now runs the program three
times. First for LISTCONFIGS, then EXPORTSUPPORTED, and again
LISTCONFIGS+INITREMOTE. It would not be hard to eliminate at least
one of those, and it should be possible to only run the program once.

doc/special_remotes/external/example.sh

@@ -137,7 +137,7 @@ doremove () {
 	local loc="$2"
 
 	# Note that it's not a failure to remove a
-	# fike that is not present.
+	# file that is not present.
 	if [ -e "$loc" ]; then
 		if runcmd rm -f "$loc"; then
 			echo REMOVE-SUCCESS "$key"
@@ -155,6 +155,12 @@ echo VERSION 1
 while read line; do
 	set -- $line
 	case "$1" in
+		LISTCONFIGS)
+			# One CONFIG line for each setting that we GETCONFIG
+			# later.
+			echo CONFIG directory store data here
+			echo CONFIGEND
+		;;
 		INITREMOTE)
 			# Do anything necessary to create resources
 			# used by the remote. Try to be idempotent.