More consistent LTO diagnostic handling

[Gao, Yunzhong via llvm-commits]

Hi Rafael,
With upstream r220608, lto_codegen_add_module() is switched to using the new diagnostic handler
mechanism; however, there are quite a number of API calls in tools/lto/lto.cpp that are still passing
around a std::string& in order to collect diagnostic messages (e.g., lto_module_create,
lto_codegen_set_pic_model, etc.). Currently I can use lto_get_error_message() to query the error
messages from all other API calls but just not from lto_codegen_add_module(). Is it possible to
make the behavior more consistent? Maybe we will want to switch all other API calls to using the
diagnostic handler too?

One idea that I have:
1. add a std::string& reference member to the LTOCodeGenerator class, with setter/getter methods.
2. lto.cpp uses the new setter method to set the location of the diagnostic messages (e.g., during
   lto_codegen_add_module) instead of passing around the std::string&.
This idea has the potential to unify the diagnostic handling of lto_codegen_?? APIs such as
lto_codegen_compile and lto_codegen_write_merged_modules, but is not helpful for non-codegen
APIs such as lto_module_create. If a client uses lto_codegen_set_diagnostic_handler to specify
a custom handler, those non-codegen APIs are still not affected.

Suggestions? Advice?

Many thanks in advance,
- Gao