In order to calculate the writeout bandwidth we need to know how long
it took to write the data to peristant storage in addition to how much
was written.
By scheduling the control data to be maintained (entries index written
and headers updated) once activity occurs to update these control
structures rather than a single serialisation at browser exit the data
is more likely to be up to date and not lost on a crash.
The data scheme fetcher was over allocating the space for decoded
base64 encoded urls and not using the base64 API that allocated the
correct size storage.
Previously content handler debugging features were accessed by global
variables. This allows the setting of debugging parameters via a
content API giving per content control over debugging features.
Currently only used by the html content handler to toggle global
redraw debugging.
The frontends previously had to use an html renderer API to get the
encoding of a content. This also required the explicit checking of the
contents type rather than using the existing content API to abstract
this knowledge.
Update the API which allows frontends to acquire the page features
(images, link urls or form elements) present at the given coordinates
within a browser window.
By making this an explicit browser_window API and using the browser.h
header for the associated data structure with a more appropriate API
naming the usage is much more obvious and contained.
Additionally the link url is now passed around as a nsurl stopping it
being converted from nsurl to text and back again several times.
The die() API for abnormal termination does not belong within the core
of netsurf and instead errors are propogated back to the callers.
This is the final part of this change and the API is now only used within
some parts of the frontends
By using an error code return we can gracefully handle fetcher
registration faliures instead of just immediately aborting.
The curl handler was also cleaned up and documentation improved
as a side effect.
The netsurf.h header should *only* contain the registration, core
initialisation and finalisation methods. Version information is best
placed in its own header.
Also remove any unneeded inclusion of this header limiting it to
solely the places the relevant API is required.
