Introduce cocoapods

[cvasilak]

Motivation: This PR add's convenient cocoapods support in the fh-ios-sdk so it can be easily installed by devs that use this kind of installation method. During this work, more cleanups were made to ease the maintenance burden. In particular:

• The README.md has been updated with detailed instructions of the steps required when doing a release in Cocoapods plus GitHub. Previously the release (framework/api docs generation) was scattered in separate scripts and procedures but currently we utilise cocoapods as the tool to encapsulate the process under a common umbrella, with clear visible steps. We are actively looking the coccoapods approach and if it will make sense in the 'productization' phase, if not all this separate steps and Xcode targets will be encapsulated in a single script rather the scatter in multiple places. The cleaning work that has been done in this PR will help us later on.
• The examples included in the /demos folder use a Podfile now and were converted to utilise the 'Development Pod' feature of cocoapods so opening a demo links to the original source's (e.g symbolic link), no need for a separate pod install once a library change is made. This will help during dev and debugging so the changes are immediate visible. @wei-lee this means that you can have the demo application only open, make changes to the library and be immediate visible ;)
• /docset folder was removed and the installation instructions for documentation were updated in the 'gh-pages' branch. No separate sync/rebase/merge is required during release. Further, the branch was cleaned up to include only the docs so it is more clear now. A separate PR (ready) will be opened to include those change shortly after this but you can have look at the README.md. Eventually, as part of FHMOBSDK-61 work, this branch will be removed and the API documentation will be moved to the fh documentation site.

Notes:

• Podfile.lock and /Pods folder is included in the repo per best practises. Although it's debatable for the Pods/ we came to conclusion that pros overshadow the cons. This doesn't affect the client usage at all since they don't come across, but add's convience during our our SDK development and any external user that comes across to the SDK.

To test:

• open fh-ios-sdk.xcworkspace, Build/Tests should both complete successfully.
• The fh-ios-sdk-blank-app used in the App Studio has been converted to use the Podspec so you can pod install and fire up the application to test. Currently the demo uses a private repo but once the PR is merged I am going to push the Podspec to the official cocoapods repository as our first release, and be immediate visible to outside developers

Next step is to look at supporting a cocoapod build inside the fh-digger-node built farm, as part of FHMOBSDK-60

[cvasilak]

@wei-lee @corinnekrych mind to review

[corinnekrych]

:eyes:

[corinnekrych]

@cvasilak @wei-lee is the choice to have Pods folder to ease build farm build? +1 for development pod, I've tried it on another project and it's very nice when you have demos in same repo +1 for Podfile.lock But still wondering for Pods folder. Still looking in more details :eyes:

[corinnekrych]

@cvasilak Great work! I've done a small PR on your PR to remove warning on cocoapods https://github.com/cvasilak/fh-ios-sdk/pull/1

@vibe13 are you ok on removing build.sh in favor of cocoapods private repo for building?

[wei-lee]

@cvasilak :+1: This is great. Indeed build farm doesn't support cocoapods yet. But we don't need to build the sdk using build farm. We can still use the generated FH.framework in the apps.