Do not overstrike settings items when searching all scopes
Sort items based on filter string when searching all scopes

When only searching current scope we want to list the settings in the order of precedence but that does not make sense when searching all scopes.
Make ‘untitledSavePath’ a public (readonly) property
Use std::mutex and std::lock_guard instead of pthread_mutex_t

Also move the mutex out so that other functions can lock it.
Remember which path a property section is extracted from
Use higher order function to collect settings
Add settings_info_for_path to get path/section for .tm_properties
Include items from .tm_properties in bundle item chooser
Set path/directory for bundle item chooser (for .tm_properties)
Allow editing .tm_properties files from bundle item chooser
Use Core Animation to fade out tool tips
Order out any old tool tip that might exist when showing a new
Hide OakToolTip interface in implementation file

This isn’t actually a public interface.
Improve ordering of items in bundle item chooser

Previously we would alphabetize (non-setting) items when filtering on other properties than the title, now we order them based on their scope precedence.

So e.g. filtering on key equivalent will now show the item that will actually fire as the first one.
Skip menu item separators with items from multiple bundles

The only example of this that I am aware of is ⌘Y when there is no version control system used for the current project: Here we get a menu with init/checkout/help items from some of the SCM bundles and it looked bad when TextMate would use separators for these items.
Allow printing WebViews even when they are not first responder

Starting with 10.9 (I think) it seems that when the WebView switches content view to show a PDF, it will lose first responder status, so pressing ⌘P (to print the PDF) does not work, but require the user to first click the PDF (to make the view first responder).

This commit uses a heuristic to figure out which view should be printed when the first responder is not a printable (web/PDF) view.
Update dialog-1.x plug-in
Use Core Animation for the open document animation (zooming icon)
Ensure our HTML output view is first responder after load

When redirecting to a PDF file the PDFView (inside the WebView) is not made first responder (on 10.9, it might have worked on 10.8).
Move WebView related print support to OakHTMLOutputView