Consider to switch to SPIR-V Tools format of text representation (assembly)

[AlexeySotkin]

It looks beneficial to have unified format.
This should also fix KhronosGroup/SPIRV-LLVM#199

[neildhickey]

For this activity we'd need to switch to using the SPIR-V Tools In-memory format for representing the SPIR-V objects, then we can make calls directly into libspirv_tools to perform the toText serialization. We can also then standardise on other parts of the SPIRV-Tools repo, such as SPIR-V parsing.

I think it will entail reworking a lot of the classes in libSPIRV, Module, Function, BasicBlock etc to at least include the same implementation objects as the SPIRVTools repo, we could replace the existing classes with an adaptor of the SPIRVTools classes to allow the interface to SPIRVReader et al to be the same. This would at least allow work to continue on supporting Vulkan in parallel.

I expect about a month of work. We'd also need to modify the tests to use the new textual format.

[AnastasiaStulova]

OpenCL TSG call July 31:

• Makes sense to keep API unchanged
• Submodule might be a problem for adoption by LLVM but probably we have to worry about it later as there are not many other options for integrating external repos.