Moved the G_MAIN_POLL_DEBUG stuff to gmain-internal.h

Now that code is about to drift from gmain.c into the poll backend,
the debug infrastructure should better be shared in the header.
I'm too lazy to deduplicate it in gpoll.c, though.
Factored the poll backend out of GMainContext

Defined GMainContextFuncs, the backend vtable for
pluggable main loop implementations.
The new constructor g_main_context_new_custom() can be used
to create contexts with custom backends (and is used internally
for built-in backends).

This first backend, made largely from the existing code, is special
in another way: the methods of GMainContext that were designed around
GPollFunc will be only supported by the poll backend.
The context will switch to the poll backend to complete
any of these functions.
Added the epoll backend for GMainContext

The new backend necessitates other changes:
Now that adding and removing descriptors to the poll may
produce failures, some of which are benign, it's important to
handle the failures when blocking and unblocking sources for recursion,
so that we don't end up in a more serious error when e.g. unblocking
a source that has had its descriptor closed and then
"temporarily" removed from the poll for dispatch.
Erased the run/quit functions from GMainContextFuncs

These are a dead API: any existing or planned backend supports
single-step iteration. They introduce functionality regressions.
They needed to go, but I prefer to leave them in the history
for reference.
Make use of the epoll backend, with a runtime fallback to poll

Falling back to poll is done in two cases:
1. At construction, if epoll_create fails.
2. When the client calls g_main_context_set_poll_func().
Internalized g_main_context_reset_compat_polls()

It can always be called from g_main_context_prepare().
We also call it from g_main_context_query(), because we
should try not to break it for the existing applications that
iterate the context by themselves via the low-level functions.
Block the source lazily, when the iteration actually recurses
Don't remove fds piecemeal when the GMainContext is being destroyed

It's useless work and unnecessary system calls for epoll.
Exempt the internally managed GPollFDs from the reset loop

We don't need to fear anybody changing their event masks,
and revents are correctly zeroed by dispatch processing.
Don't reset revents in the compatibility fd support loop

Doing so brings more harm than good, because we can clobber events
that were reported, but not dispatched due the source's low
priority. The revents fields for dispatched sources are correctly
reset after dispatch. If the application polls our fds itself,
it will pass back the fds with zero reported events to
g_main_context_check() as per good old poll semantics.

Care should be taken with recursive sources, however: these should
only see revents on their fds zeroed after the outermost dispatch
has returned. Yay, a use for G_HOOK_FLAG_IN_CALL again.
glib/gmain-epoll.c: Shut up Valgrind
GMainContext backend vtable is passed as const

GMainContext does not modify the table of backend functions, and
the most common use case for backends is to create a constant
table. If a backend wants some method rewriting magic, it's still
possible, but the GMainContext does not need to know.
Make GMainContext backend's iterate method dispatch sources

Third-party backends such as libuv need to call dispatch anyway when
the event loop is not driven by glib.
As an added benefit, the backends' implementations of iterate
look like a complete cycle now.
Added a missing lock when querying the poll records
Support non-pollable descriptors in the epoll backend

Backward compatibility dictates that we report events even on those
descriptors which epoll does not support.