Fix potential lockup with search-provider

Because there were no comments as to why some long-long-ago decisions were made, it was lost on me that GCalc doesn't appear to have halting protection. That means the inline of the search provider could lockup on something like "10!!!".

To avoid this, I've gone back to a subprocess but invoke the same process (gnome-calculator-search-provider) so that it is easier to avoid some of the extra work on startup. Particularly we can avoid GSettings initialization in most cases by passing that information from the parent process which already has that information loaded/cached.

With the subprocess approach, most of our overhead is now just loading shared libraries by the linker. The dynamic linker represents about 90% of the subprocess run time.

To work around that in the future, we could either:

• Drastically reduce the number of dynamic libraries (which means not using things like GtkSource.Buffer to represent a math equation).
• Use an intermediate proxy process which passes along the search provider to a subprocess and SIGKILL it if a message times out.

The second one would have the added value that it's probably useful for other projects which may have some level of halting issues.