Improve our handling of rtti/sanitize=vptr/sanitize=undefined

This patch removes the huge blob of code that is dealing with
rtti/exceptions/sanitizers and replaces it with:

A ToolChain function which, for a given set of Args, figures out if rtti
should be:
  - enabled
  - disabled implicitly
  - disabled explicitly

A change in the way SanitizerArgs figures out what sanitizers to enable
(or if it should error out, or warn);

And a check for exceptions/rtti interaction inside addExceptionArgs.

The RTTIMode algorithm is:
  - If -mkernel, -fapple-kext, or -fno-rtti are passed, rtti was disabled explicitly;
  - If -frtti was passed or we're not targetting the PS4, rtti is enabled;
  - If -fexceptions or -fcxx-exceptions was passed and we're targetting
    the PS4, rtti was enabled implicitly;
  - If we're targetting the PS4, rtti is disabled implicitly;
  - Otherwise, rtti is enabled;

Since the only flag needed to pass to -cc1 is -fno-rtti if we want to
disable it, there's no problem in saying rtti is enabled if we're
compiling C code, so we don't look at the input file type.

addExceptionArgs now looks at the RTTIMode and warns that rtti is being
enabled implicitly if targetting the PS4 and exceptions are on. It also
errors out if, targetting the PS4, -fno-rtti was passed, and exceptions
were turned on.

SanitizerArgs now errors out if rtti was disabled explicitly and the vptr
sanitizer was enabled implicitly, but just turns off vptr if rtti is
disabled but -fsanitize=undefined was passed.

Also fixed tests, removed duplicate name from addExceptionArgs comment,
and added one or two surrounding lines when running clang-format.
This changes test/Driver/fsanitize.c to make it not expect a warning when
passed -fsanitize=undefined -fno-rtti, but expect vptr to not be on.

Removed all users and definition of SanitizerArgs::sanitizesVptr().

Reviewers: samsonov

Subscribers: llvm-commits, samsonov, rsmith

Differential Revision: http://reviews.llvm.org/D7525

llvm-svn: 229801