So as to catch incorrect usage of the APIs as soon as possible.

https://bugzilla.gnome.org/show_bug.cgi?id=780707

We'll maintain the C code until Rust is stable enough to integrate in
Gnome.

Changelog:

* Replaced gepub-archive / gepub-doc C source with Rust epub lib

Changelog:

* Added .doap file
* go_next and go_prev returns TRUE if success
* Added functions to get the current doc mime and path
* Fixed resource path for relative and doc paths
* Remove libarchive from the public API
* Simplify pkg-config file
* Don't link the library against GTK+
* Function to replace relative resources by epub://
* utils: replace epub:// URIs for crosslinks too
* utils: correctly terminate base URI
* doc: fix wrong path when looking for resources
* doc: make API to get resources consistent
* Added GepubWidget class to show the content with webkit
* Don't NULL-terminate document content
* utils: remove unused variable
* build: highlight introspection warnings
* build: fix introspection warnings
* Merge branch 'wip/cosimoc/fixes'
* Fixes in gepub-widget to work with the last merge
* widget: make it a WebKitWebView
* widget: simplify code
* Fix gtk-doc annotations
* widget: make the GepubDoc a property
* doc: remove unneeded API
* doc: use htmlReadMemory()
* widget: plug a memory leak
* Rework API to be based on GBytes
* doc: trivial indentation fix
* Const-ify API methods that take strings
* doc: don't call g_list_append()
* doc: rework page API
* widget: automatically reload chapter when current page changes
* Ignore HTML entities parse error when loading xml

I've added two new properties to the widget, the current page and the
number of pages in the chapter.

The number of pages is getted from javascript, because I'm paginating using
javascript and css.

We use libxml to load the xhtml and replace each resource path with a
custom epub:// path. Libxml shows error in the stderr when the xhtml has
html entities:

Entity: line 21: parser error : Entity 'copy' not defined

We don't mind html entities in this case, because we only want to replace
resources path so I've replaced xmlRecoverMemory by xmlReadMemory to pass
the parser options XML_PARSE_NOWARNING and XML_PARSE_NOERROR and we won't
see the error in the console anymore.

Instead of having the widget client manually call reload(), which has
now been made an internal method.

Instead of directly exposing the spine, add API for pages directly.
Previously, one had to make sure to call get_spine() and store the
result before any other call to go_prev()/go_next(), since the list
length would have otherwise changed.
Now we separately track the current page, and make it a property so that
views can listen to changes.

It's more efficient to always prepend to the list and then reverse it at
the end, since g_list_append() will walk the list at every call.

This is more convenient to use, and the format ultimately expected by
the WebView widget.

Since we have a size, this is the correct method to use.

The fact that GepubTextChunk is an object is visible to the clients of
the API, so there's no need to have a custom wrapper to free the
objects.

Instead of having a mismatched get_doc/load_epub. This changes the API
slightly so that clients will need to create the GepubDoc before passing
it to the view.

There's no reason to make this a box with a single child. Derive
directly from WebKitWebView.

We should not try to modify the contents of the archive by inserting
newlines, as e.g. WebKit will complain that there's extra data at the
end of the stream.

This new widget shows the epub content using webkit2gtk. The new widget
inherites from GtkBox and at first it only shows a WebKitWebView with the
current doc page, but the idea is to be able to paginate and show two pages
at the same time, for the landscape view.

Right now there are _by_id() variants for certain methods, but the id is
used by default for others. Make it consistent by always having the
unsuffixed methods take a path.

The client will already pass the full path here. Don't try to mangle it
again.

Or we'll fail to resolve relative paths.