Fix: Removed adam's Library Search Paths

• Removed a number of Library Search Paths from the xcodeproj that were pointing to hard-coded `/Users/adam/workspace/openFrameworks/addons/ofxTimeline/libs/…` dirs.
	» They were producing linker warnings like: `Directory not found for option '-L/Users/adam/workspace/openFrameworks/addons/ofxTimeline/libs/openal/libs/vs2010/EFX-Util_MT'`.
	» The fact that these are hard-coded paths, and that they include a library that OFPlugin doesn't use (ofxTimeline) seems evidence enough that this is just an unintended mistake.
Moved OF menu to under the Xcode menu

So… here's the thing.  OFPlugin really shouldn't have its own menu, because… that's not really how menus work.  I mean, it's a great idea and all, or would be a great idea if we all had screens that were 30"-wide.  Or if OS X were really designed around menu bars— like, if we could drag menus off to floating palettes, and if too many menu items added a little “more items” icon… you know, if they worked like app toolbars do.  But they don't.  OS X's menu bar is somewhat of a broken UX concept as it is— if there's not enough room it just starts truncating stuff, and many 3rd-party always-running extension (like Dropbox and every competing service) already fight for what space there is.  And Apple's not making things better by introducing Retina displays— the future is high-res, not real-estate.  So… I hate to have to do this but… the OF menu has to be under a different menu.  I mean, I still love you OFPlugin, but you gotta play along with everyone else.  We don't want people deleting you just because you standing in the wrong spot.  This is for the best, okay? <3

On a more serious note…

• Moved the “OF” menu to a “openFrameworks” menu item section under the Xcode menu, after the Open Developer Tool/Services section and before the Hide/Show section.
	» “Menu item section” as in “separated by menu item separator lines”; it add both a new separator and the item.
	» Searches for the “Xcode” menu first by name, falling back to using a hard-coded `kExpectedXcodeMenuIndex`.
	» Searches for the first “Hide…” menu item first by name, then falling back to `kExpectedXcodeMenuPreHideShowSeparatorItemIndex`, and finally ensuring that it isn't past the end of the end of the existing menu items.  We really don't want this to cause any future version of Xcode to crash— it's far better for it to be in the wrong spot.