[wishlist] submodule.update config

Relates (but orthogonal) to my other thread

  [wishlist] git submodule update --reset-hard

ATM, it possible to specify per submodule update strategy via configuration variable submodule.SUBMODULE.update where SUBMODULE is the name of the corresponding submodule. But I see no way to specify default update strategy for all submodules.

From our conversation in that other thread I have discovered to myself about existence of submodule.recurse configuration, and there seems to be a few more (.fetchJobs, .active) where e.g. .active seems to complement per-submodule submodule.*.active:

	yoh@debian:~/proj/misc/git$ git grep '[^.]submodule\.[a-z]' -- Documentation/
	Documentation/RelNotes/2.14.0.txt: * Many commands learned to pay attention to submodule.recurse
	Documentation/RelNotes/2.15.0.txt: * "git -c submodule.recurse=yes pull" did not work as if the
	Documentation/config.txt:include::config/submodule.txt[]
	Documentation/config/submodule.txt:     update'. If neither submodule.<name>.active or submodule.active are
	Documentation/config/submodule.txt:     interact with submodules; settings like `submodule.active`
	Documentation/config/submodule.txt:     submodule.active config option. See linkgit:gitsubmodules[7] for
	Documentation/config/submodule.txt:     as computed via `submodule.alternateLocation`. Possible values are
	Documentation/git-clone.txt:    of multiple entries.  The resulting clone has `submodule.active` set to
	Documentation/git-clone.txt:    Defaults to the `submodule.fetchJobs` option.
	Documentation/git-submodule.txt:If no path is specified and submodule.active has been configured, submodules
	Documentation/git-submodule.txt:        Defaults to the `submodule.fetchJobs` option.
	Documentation/gitsubmodules.txt:`submodule.foo.path = path/to/bar`.
	Documentation/gitsubmodules.txt:The section `submodule.foo.*` in the `.gitmodules` file gives additional
	Documentation/gitsubmodules.txt:hints to Git's porcelain layer. For example, the `submodule.foo.url`
	Documentation/gitsubmodules.txt:  b. if the submodule's path matches the pathspec in `submodule.active`
	Documentation/gitsubmodules.txt:submodule's path is excluded in the pathspec in `submodule.active`, the
	Documentation/gitsubmodules.txt:  git config --global submodule.recurse true
	Documentation/gitsubmodules.txt:your working tree. Alternatively you can set 'submodule.recurse' to have
	Documentation/technical/api-config.txt:if (!git_configset_get_bool(gm_config, "submodule.frotz.ignore", &b)) {
	Documentation/technical/http-protocol.txt:  $GIT_URL:     http://example.com/git/repo.git/path/submodule.git
	Documentation/technical/http-protocol.txt:  URL request:  http://example.com/git/repo.git/path/submodule.git/info/refs

I wondered, if you think it would be sensible to also add of submodule.update which would be considered before submodule.SUBMODULE.update variable possibly defined per submodule. That would be more inline with desire to use any of the --merge, --rebase (and hopefully soon --reset-hard) strategies specified as an option for submodule update, where no per-submodule handling is happening.

Thanks in advance for the consideration!