Core browser functionality

As you will all no doubt have noticed I have been splitting the
browsers core functionality out from the front ends. The evantual aim
of this work is to be in a position to have a browser library around
which frontends can implement a browser suitable for their platform.

The functionality falls broadly into these catagories:

1) "library" type functionality which each frontend can use to perform
actions (like nsurl for handling urls and message code for handling
internationalised strings) which is mainly provided in the utils
directory.

2) Core browser functionality which provides everything from the
fetchers to the renderer.

3) Operations the core code requires the frontend provide. These are
accessed through an operations table which is currently initialised as
part of gui_init()

4) Frontend code.

My work so far has mainly been in the third area, but I am considering
all but the frontend code in this discussion.

I would like to start moving functionality out of the netsurf project
and into a core library. I think I have progressed the refactoring
work far enough that this is a useful thing to start.

To be clear this is *purely* a reorganisation of code. The new library
would remain licenced as now (GPL v2+openssl exception, unlike our
other libraries which are MIT) and all functionality would remain
unafected.

The new library would use the core buildsystem however and be built as
part of the CI system.

The aim here is to have a clear identifiable boundary between what is
frontend code (which will remian in the netsurf project as now) and
what is core browser.

This move would emphaticaly *not* be an instant change, more a gradual
movement of functionality as it becomes clear where it belongs.

My first addition would probably be to move the gui_factory operation
table functionality and cause it to be used for the ns_register() very
early in all the frontends main() which should remove some of teh
issues ChrisY has experienced as fallout from my rcent refactors.

I want to get input on this from everyone, especailly from Chris and
Steve who have put up with my breaking their frontends with my
refactors and with whom I do not get to communicate with a great deal
on these things.

If we decide this split is a good idea I want to decide the library
name as well. If we follow the existing netsurf support library
convention it would be called "libns" and all exported functions would
be prefixed with "ns_"

This name fits reasonably well except it is a bit close to cocoa
library naming where everything is prefixed with "NS" (for nextstep),
This does not conflict (as nsurl etc. currently show) but might be
confusing?

Other options are libnscore and libnsbrowser. However please remember
we prefix all exported functions with that name so nscore_ and
nsbrowser_ are a bit long. e.g. nsurl_ctreate() becomes nscore_url_create()


This is intended as a discussion start, if you are a current committer
please do comment!

--
Regards Vincent