[doc]Update String Error documentation in Programmer Manual

[jhenderson]

Summary

A while back, createStringError was added to provide easier construction of StringError instances, especially with formatting options. I noticed today that the documentation only mentions the standard method of using it. Since createStringError is slightly shorter to type, and also provides the formatting options, this patch updates the Programmer's Manual to use the new function in its examples, and to mention the printf formatting options. It also fixes a small typo in one of the examples and removes the unnecessary make_error_code call.

[JDevlieghere]

LGTM

[jhenderson]

Oops, forgot to mention the review in the commit. This was committed as rL352846.

docs/ProgrammersManual.rst

 StringError
 """""""""""
 
 Many kinds of errors have no recovery strategy, the only action that can be
 taken is to report them to the user so that the user can attempt to fix the
 environment. In this case representing the error as a string makes perfect
 sense. LLVM provides the ``StringError`` class for this purpose. It takes two
 arguments: A string error message, and an equivalent ``std::error_code`` for
-interoperability:
+interoperability. It also provides a ``createStringError`` function to simplify
+common usage of this class:
 
 .. code-block:: c++
 
-  make_error<StringError>("Bad executable",
-                          make_error_code(errc::executable_format_error"));
+  // These two lines of code are equivalent:
+  make_error<StringError>("Bad executable", errc::executable_format_error);
+  createStringError(errc::executable_format_error, "Bad executable");
 
 If you're certain that the error you're building will never need to be converted
 to a ``std::error_code`` you can use the ``inconvertibleErrorCode()`` function:
 
 .. code-block:: c++
 
-  make_error<StringError>("Bad executable", inconvertibleErrorCode());
+  createStringError(inconvertibleErrorCode(), "Bad executable");
 
 This should be done only after careful consideration. If any attempt is made to
 convert this error to a ``std::error_code`` it will trigger immediate program
 termination. Unless you are certain that your errors will not need
 interoperability you should look for an existing ``std::error_code`` that you
 can convert to, and even (as painful as it is) consider introducing a new one as
 a stopgap measure.
 
+``createStringError`` can take ``printf`` style format specifiers to provide a
+formatted message:
+
+.. code-block:: c++
+
+  createStringError(errc::executable_format_error,
+                    "Bad executable: %s", FileName);
+
 Interoperability with std::error_code and ErrorOr
 """""""""""""""""""""""""""""""""""""""""""""""""
 
 Many existing LLVM APIs use ``std::error_code`` and its partner ``ErrorOr<T>``
 (which plays the same role as ``Expected<T>``, but wraps a ``std::error_code``
 rather than an ``Error``). The infectious nature of error types means that an
 attempt to change one of these functions to return ``Error`` or ``Expected<T>``
 instead often results in an avalanche of changes to callers, callers of callers,