Instead of a `git_bom_t` that a `git_buf` function returns, let's keep
it `git_buf_bom_t`.

The `git_buf_text` namespace is unnecessary and strange.  Remove it,
just keep the functions prefixed with `git_buf`.

`git_buf_copy_cstr` is called with user-input, and wants to sanity-check
that input.  Allow it to return a value if the input was malformed in a
way that we cannot cope.

`git_buf_sanitize` is called with user-input, and wants to sanity-check
that input.  Allow it to return a value if the input was malformed in a
way that we cannot cope.

Allow users to consume a buffer by the number of bytes, not just to an
ending pointer.

Signed-off-by: Sven Strickroth <email@cs-ware.de>

Introduce a function to take a percent-encoded string (URI encoded,
described by RFC 1738) and decode it into a `git_buf`.

Both the `git_buf_init` and `git_buf_attach` functions may call
`git_buf_grow` in case they were given an allocation length as
parameter. As such, it is possible for these functions to fail when we
run out of memory. While it won't probably be used anytime soon, it does
indeed make sense to also record this fact by returning an error code
from both functions. As they belong to the internal API only, this
change does not break our interface.

When `git_buf_sanitize` gets called, it converts a buffer with NULL
content to be correctly initialized. This is done by pointing it to
`git_buf__initbuf`. While the method's documentation states this
clearly, it may also lead to the conclusion that it will do the same to
buffers which do _not_ have NULL contents.

Clarify behavior when passing a buffer with non-NULL contents, where
`git_buf_sanitize` will ensure that the contents are `\0`-terminated.