Project realignment

Creating a feature branch for the project/repo realignment.  This is a work in progress, but here's what I've done so far.

- Created a git repository and submodule for third party libraries, unarchived out to their folder structures, as they would be consumed.  This submodule lives at `external/ThirdPartyLibraries`.
- Created a new `SalesforceSDKCore` library (in shared/), which encapsulates all of the code that used to be shared as source between the native and hybrid libraries.  Moved all of the appropriate unit tests from the `SalesforceSDK` project into this one.
- Moved the `SalesforceOAuth` library into shared/ as well.  The concept of native/ and hybrid/ should apply to the SDK business separations, not the architecture of the code; it's all native, in that sense.
- Renamed the SalesforceSDK native library to SalesforceNativeSDK, for parity with the SalesforceHybridSDK library to come.
- Created an Xcode workspace at the root of the repo (`SalesforceMobileSDK.xcworkspace`), which will contain all of the projects whose source we are responsible for.  This currently functions through the core to native SDK stack; hybrid is next.

**What does this mean to me?**

Glad you asked.  Development in the SDK just got a whole lot simpler to set up and manage.  The steps look roughly like this:

1. Clone the repo and sync the submodules.
2. Open the workspace.
3. There is no step 3.

- Everything in the workspace is linked in the development environment; dependencies do not have to be staged.
- Everything can be debugged through, top to bottom.
- Changes to the underlying dependencies are picked up automatically, in real-time.  Make a change to the OAuth library code, then test it by running the RestAPIExplorer target.  Or one of the unit test targets.  That's it.

**What's left**

- Need to do the hybrid side, which involves:
    - Refactoring the Hybrid framework to a static library.
    - Cleaning up the hybrid project, particularly the over-proliferation of test projects, and spaghetti-linking of files all over the place.  Ick.
    - Extricating Cordova from the hybrid SDK, as simply another dependency.  **Note:** Given that we routinely manage our own code extensions to Cordova, I'm considering pointing the Cordova project from the submodule into the workspace as well (as opposed to staging it as a third-party binary library).  I think it fits the model of being a "code we're responsible for" first-class citizen.  And it would also be helpful for debugging down into Cordova from time to time.
    - Lining up all of the hybrid project (and sample apps, etc.) in the workspace, as the native has been done.
- Need to refactor the build scripts.  The build scripts will no longer need to pull their predominant duty of shuffling files around.  Instead, they'll be used to package the end product libraries for staging to our binary repo to come.

Feel free to try out the workspace now; as I said, the native side is done.  And it's a darn sight nicer to work with than it has been in the past.  Let me know if you have any questions.