Clean up some error handling and change callback error behavior

This PR has a few error handling improvements that I've been playing with. You folks may consider them to be too intrusive, but I figured I'd open it up and get the conversation started.

There are two main areas changed here:

1. Creating internal APIs for looking up config values without a GIT_ENOTFOUND error, and
2. Changing callback to pass the return code back to the user instead of converting it to GIT_EUSER.

----

For handling config value access, I added a new **internal-only** function:

```c
extern int git_config__lookup_entry(
  const git_config_entry **out,
  const git_config *cfg,
  const char *key,
  bool no_errors);
```

This looks up a specific key (*no normalization is applied, so it must already be in normal form*) and returns the found entry or NULL if it was not found. Not finding the key is not considered an error. There is an extra `no_errors` parameter that suppresses all errors completely to silently continue in cases where there is config file corruption and an operation where accessing a config value is non-critical is performed. (This differs from core Git, but until we have a "warning" mechanism, I prefer it.)

There are also three helper functions to get a string, bool, and int from the config with a fallback value to use if the value is not found or if an error is encountered.  These are named `git_config__get_string_force`, `git_config__get_bool_force`, and `git_config__get_int_force`. I'm not sure about those names, so opinions are welcome -- I'm was trying to imagine a `--force` flag being applied to config lookups.

In places where a known configuration setting is being looked up (i.e. the name of the config is not coming from user input) and a `GIT_ENOTFOUND` is to be ignored, I inserted this new function which has a streamlined path and leaves no error to be cleared.

----

I experimented with a number of different cleanups for callback functions and `GIT_EUSER`, initially trying to make sure we were reliably clearing the last error, stopping the operation in progress, and returning `GIT_EUSER`. However, after some discussion (see below in this PR), I ended up changing the fundamental behavior with callbacks so that we would instead stop the operation in progress and pass the user-returned error code back to the original caller. In these cases, I still put a call to a new function `giterr_set_after_callback` that sets a generic error message if the callback did not use `giterr_set_str` to set on explicitly. This way, there should always be some message set when a function returns non-zero, even if the source was a user callback.

I also added a couple of convenience functions `giterr_capture` and `giterr_restore` for internal use when we need to take a snapshot of the current error state on a thread and then restore it after making some function calls that could mess it up. This is convenient when you need to perform some cleanup after an error and/or cancel is detected.

----

There are a variety of other unrelated error handling fixes that I put in as I was going through the code. There were a number of functions that were either not checking allocations or were replacing error return codes with `-1`. Those fixes are scattered around.

I also fixed an apparent bug in `git_branch_move` where the config was updated before the reference was altered. As a result, if the reference change encountered a conflict, the config settings would be trashed and not restored. I swapped the order in which the steps are executed to fix this and added some new tests to cover this case.

I also fixed an inefficiency in `reference_matches_remote_head` inside the clone code where once a match was found, we continued to iterate over all reference names (just immediately returning from the callback) instead of returning something like `GIT_ITEROVER` to stop the iteration.

----

Anyhow, hopefully this hasn't gone too far off the tracks and there is some value in it. There are a number of other fix ups I'd still like to do (such as dealing with the `GIT_ENOTFOUND` from looking up environment files -- i.e. the system, global, and XDG files) and there are definitely more places where we are not propagating error codes correctly (I saw several in the networking code). However, I'd prefer not to let this grow to be too large (particularly since it gets conflicts easily) and see if we can get something mergeable that will be an incremental improvement for some of the error issues.