Implement convenience function for submodule update

This is a PR for the work in progress to include a convenience function for submodule update functionality.

The 1st and 2nd commits bring relative URL paths in gitmodules in line with core git.

The 3rd commit introduces a `git_submodule_do_update` function. One place in particular I was looking for thoughts was the `git_submodule_update_options` struct. There are several ways this could be done. Initially, I have chosen to just expose the properties that I think might make sense on this struct. Also, there is already a function named `git_submodule_update` that is a getter for a config setting, which feels out of place with `git_submodule_sync` and `git_submodule_init` - it seems this should be the function for performing a submodule update.

It also seems that there are several functions that are much less useful after the updates to the clone API - in particular `git_submodule_add_setup`, `git_submodule_add_finalize`, and `git_submodule_repo_init`. These set up / finalize a series of steps where you can setup a repository and then clone into it, but the `clone_into` function is no longer exposed. Is there a reason for `git_submodule_add_setup` to exist? or should these be replaced with a more appropriate API for adding a submodule?
Yes, for reading you have to go through a snapshot, unless you know that nothing is going to access the config object in any way until you stop using the pointer you got back. Even reading from the config can cause the pointer to be invalidated, which includes access from other threads or a second `_get_whatever()`.

I realise it's a bit silly to have to switch between snapshot and live when you're writing and reading, and I'm working on a way to keep the live semantics while making it concurrency-safe.