config: make type conversion explicit

The type of a config value depends on the tool that interprets
it. Parsing eagerly can lead to a situation where we return a bool
instead of a string or a number.

Let the user specify the type themselves by passing in a (str, type)
tuple into the mapping interface.
Get ready to release 0.20.3
Start implementing remotes with CFFI

This moves enough code into python with CFFI to pass the test_remotes
unit tests. There is no credentials support yet.

There is a small change in the return value of Remote.fetch() in that we
now return a TransferProgress object instead of extracting a few values
into a dictionary.
Remote: support credentials via CFFI
Remote: add support for transfer and update_tips though CFFI
Remote: add documentation strings

Now that it has the features of the old implementation, let's add
documentation on how to use it.
Remote: get rid of the C code

This code has been obsoleted by the CFFI-using code. Some credentials
code remains in C due to the clone functionality making use of it.
Implement clone via CFFI as well

This lets us get rid of the last piece of C for anything related to
remotes and credentials.
Config: make bool and int parsing explicit via functions

Passing a tuple to the mapping interface isn't the best of interfaces,
as the key is only the string.

Instead, expose `Config.get_bool()` and `Config.get_int()` methods to
parse the values as per the git-config rules before returning the
appropriate type to the user.

The mapping interface itself returns a string.
Merge remote-tracking branch 'carlos/config-parse'
Some python3 fixes
Install the "decl.h" file
Remote: make sure to take the contents of the id

Pass the contents of the buffer containing the git_oid to bytes() so
build a raw representation of its contents. Using bytes(ffi.buffer(...))
returns the representation of the buffer.
Depend on the cffi package

Let both pip and Travis know what we need.
Fix installation-time cffi compilation

The documentation recommends adding the ffi code as an extension so it
gets built at the right time.

Make use of the LIBGIT2 environment variable to build and link the ffi
module the same way the C extension does so the user doesn't have to
export CFLAGS.
Safer repository pointer extraction

Casting a pointer to a non-pointer type is something which you should
never do. Instead, do something a bit more convoluted, but which is
guaranteed to give us the right pointer, as well as making sure that the
memory we exchange between python/cffi and the C extension is of the
right pointer size.

While we're touching this code, fix which object we pass to the Remote
constructor to keep alive. We need to pass the Repository object to
stop it from becoming unreferenced (and thus freeing memory the remote
needs) instead of the git_repository pointer.
ffi: style changes

Make to_str() accept None as well as ffi.NULL to return as a negative
value, and grab the version in a more compatible way.
Update some docstrings which had got out of date.
Remote: protect against invalid input on rename

The C API expects a non-NULL new name and raises an assertion if we
don't protect against such input, so let's guard against falsy values,
which also takes care of the empty string, which is also not valid
input.
Fix config documentation keyword

The keyword for linking to a mehtod is 'meth', not 'method'. Setting the
'currentmodule' allows us to link without the 'pygit2' prefix in the
link text.