Added method to build Cocoapods dependencies as framework. Initially it should solve problem that Firebase libraries can't be built if use_frameworks! flag is not used in Podfile.

Technical details

Main

Now every Project can specify in its Podfile use_frameworks! flags which we detect and added to the final Podfile used for dependency resolution. By default use_frameworks == true for now because it was old behaviour and it can be changed after updating Firebase extensions with that flag During cocoapods dependency resolution we check is use_frameworks!` is presented and have two code paths to build dependency: as static library or as framework.

Framework build consist of:

1. Create framework structure: Headers and Modules directories.
2. Copying public headers to Headers directories
3. Copying modulemap which was generated by Cocoapods (from Target Support Files) to Modules
4. Copying umbrella headers which was generated by Cocoapods to Headers
5. Generated VFS and header map for current framework
6. Build library. As header search path uses generated header map. For module-related stuff we pass -F<path_to_current_framework>. Additionally we pass generated VFS definition. It solves problem that compiler detect the same headers in different locations which leads to errors. VFS solves it. If framework has dependencies (defined in Pod spec) we merge generated GFS from that dependencies into current framework VFS (To be short, compiler will now where to find headers for dependencies).
7. Copying result swiftmodule with correct name to the Modules directory
8. Copying Swift compatibility header
9. Updated copied modulemap with Swift module definition.
10. Copying all resource bundles and resources to framework root.
11. Generated Info.plist for framework from template which was generated by Cocoapods.
12. Sign framework.

Virtual Filesystem (VFS) and Header maps

VFS overlay and Header maps are Apple private formats which used for compile-time optimizations. VFS is a list of mappings where files used for compilation (headers) are located in the real FS. Header map is the similar mappings but it defined where to find header for different include format ("" and <>). Header map is a binary format that's why for generation I used a third-party tool hmap (installed from brew). Initially I generated headermap in json format and than convert it to binary. In headermap I include all public headers in 2 variants: "SomeHeader.h" and <SomeFramework/SomeHeader.h>. For private headers - only "" format. It solves problem when inside dependency code headers include differently - in one place via <>; in other - via "".
Also those two files should helps to avoid excessive disk operation for searching headers and as a result - faster compilation.

Other notes

• For Extender and CocoapodsService I introduced so-called "State" class which contains some values that should be used across all build process. For example, paths to build and intermediate directories. Those state passed into different build method which helps to reduce overall amount of arguments.
• Introduced PodBuildSpec. These class contains all runtime-generated information which is needed for compilation. PodSpec now contains only parsed from pod spec information, nothing else. Also PodBuildSpec has methods to add subspec if any of subspecs is defined in Podfile or during pod resolution. Now if several subspec are used they all accumulated (sources, resources, headers, flags) under one PodBuildSpec with name of main PodSpec. During the build we iterate and build PodBuildSpec (which can contains several subspec). It solves problem that several subspec should be united and presented as one static library inside framework (for example, KSCrash). When we built as static library - it doesn't matter are they separate libraries or not.
• ResolvedPods now collects all frameworks, search paths, etc. when it's initialized and used that information during build in opposite of collecting every time when information is needed. So if someone wants to update search paths during the build - it may be ignored.
• For backward compatibility I added several places (marked with // **********************) which updates compiler command for old versions of build.yml

Fixes #733