Draft: Modernize profiling code: use of sysprof instead of printing

This makes the profiling code much useful, since it can be used from sysprof. This is heavily inspired by gnome-software!1476 (merged)

Before:

After:

The main changes and their rationale are:

• Instead of having a custom profiling code, that does some printing to stdout that has to be manually parsed, allow to have a graphical visualization of the situation, as provided by sysprof. This should greatly help profiling.
• Since the use of sysprof requires an additional library, that is made optional, and profiling code only enabled conditional to the dependency being satisfied. The previous requiremnt where evince has to be compiled in debug mode is kept.
• The stop marks were before sometimes taken after the "finished" signal had been emitted by the ev-job (the only place where profiling takes place). This accounted for additional time inside GLib/GTK4 code that is probably irrelevant for the profiling of the time evince takes to execute tasks. Now, there are taken on any possible exit from the job run functions.
• This is in theory an ABI and API change. However, the functions were (and remain) all private, so unless somebody is mixing libview and libdocument libraries from different evince versions, this should be no problem.
• The old EV_PROFILE and EV_PROFILE_JOBS environment variables are now completely ignored. Those were not documented anywhere, so it is probably no issue to assume that people profiling evince should be able to read the NEWS file and adjust their workflow accordingly.

Additionally, there are a couple extra preparation commits.

I still have two wonders of things that could be improved. But certainly not a blocker:

• Could possibly the ev-profile.h file be moved to libview? ev-debug.h functions are only used there, so I wonder why it lives in libdocument.
• It would be possible, for functions that have multiple exit points, to have a scoped macro for the whole function, instead of one stop per each return. It requires more code, since it needs a struct to cleanup the data, and adding a cleanup attribute, so that when leaving the scope, the timestamp will be recorded. I didn't consider it worth it, but can be done upon request.

This also shows something relatively annoying , which is that jobs run sequentially. I'm going to be looking into replacing the scheduler implementation for a GThreadPool.