This PR addresses issue #10316 and makes submodules available in repositories created from templates.
Submodules are now inherited when creating a new repository from a template with "Git Content" checked,

Unlike the initial suggestion provided by @davidsvantesson in the original issue i decided not to use git submodule status initially because its output can look like this:

 0dff7e5493898954537202c0c975f7b1c55d0845 lib (no%_()delay)1 (heads/master)

Submodule names can contain all sorts of special characters and the (heads/master) part is not always present in the output which makes reliably parsing the name out of this quite a pain if not impossible. I replaced this step with git config -f .gitmodules --list --name-only which will give:

submodule.lib (no%_()delay)1.path
submodule.lib (no%_()delay)1.url

This is far easier to parse and provides the necessary submodule name. git submodule status lib (no%_()delay)1 is then used as second step to get the commit hash which is now easily parsed as well as there is only a single line of output.

These steps happen in the getSubmodules function and are the largest part of the change. This function does not throw any errors but will just skip broken submodules so that a template with a malformed .gitmodules file can still be used.

To re add the submodules i use git update-index --add --cacheinfo 160000 0dff7e5493898954537202c0c975f7b1c55d0845 lib (no%_()delay)1 instead of the regular git submodule add .... Updating the index directly skips cloning the submodule which is far faster and entirely avoids the problem of users adding excessively large submodules to possibly DoS attack the Gitea server. It also avoids the issue where a submodule repository might not be accessible by the Gitea server due to authentication/permissions or other reasons such as absolute local file paths being used.