CoreBase: necessary additions for WebKit

[Daniel Ferreira (theiostream)]

Hi Stefan,

I don't know if you've been following the list for my huge thread on a
TODO list that GNUstep needs to implement for WebKit[1], but among
those items are some related to CoreBase. I've scratched the surface
of how to implement some of them but I'd like your two cents before I
start working on it and possibly screw things up.

In order of priority from first to last, these are the issues:

1) Implement -[NSRunLoop getCFRunLoop]
This one is really, really needed for WebCore to set up a lot of stuff
-- and is the only one in this list we can't live without.

I can think of solving this by creating a category to NSRunLoop in
CoreBase that implements this method by creating a new CFRunLoop with
all sorts of information we can gather from the receiving NSRunLoop. I
don't know if any bizarre issues will arise, though. Does this seem
sane?

2) Implement CFNotificationCenter
We need CFNotificationCenterRemoveObserver() and
CFNotificationCenterAddObserver() for WebCore edge cases. I would be
tempted to follow the model of some current "classes" and forward
these functions' behavior to NSNotificationCenter, but in this case
(per the Apple documentation) the classes would not be toll-free
bridgeable, so I don't know if relying on the Base implementation
would be okay.

If we *can* use Base, that's great, but if we can't, I'd like to know
how you'd implement these functions. Also, is there any particular
reason why you did not implement this?

3) Implement CFPreferences
We need CFPreferencesCopyAppValue(), CFPreferencesSetAppValue(),
CFPreferencesAppSynchronize(). Once again, if I could just rely on
Base I'd use NSUserDefaults, but since this is not a
toll-free-bridgable class (or a class at all), I wonder if that's
"legal".

The same question applies here: if we can't use Base, how would we do
this? Note: for WebKit purposes, we don't need to access any
non-app-specific user defaults, so this reduces the scope of the work
that is currently needed.

We can live without this because we can change WebKit not to look for
preferences and just assume the default.

4) Missing CFLocale functions
I suppose I can figure out the Unicode functions in CFLocale by myself
to add the new functions needed by WebKit. I'll send a pull request
with it in the near future.

The same for preferences goes here -- we can mostly keep these
functions unimplemented and assume the default. These are particularly
needed by JavaScriptCore.

5) CFStringTokenizer
We lack CFStringTokenizer, which is used by WebKit if it is on iOS,
but since that's not the case of our build we can leave that alone for
now.

Aside from these ones, I am almost sure we'll need to do some
bugfixes, but nothing that I can anticipate right now.

Also, please let me know if there's any issue you'd like to work on so
I can focus elsewhere :)

-- Daniel.

[1]: http://lists.gnu.org/archive/html/gnustep-dev/2017-06/msg00040.html