[arc-codemotion] Eliminate retains that we move next to fatalErrors and unreachables.

The reason to do this is that otherwise, retain code motion can increase the
size of the IR by large amounts as it pushes tons and tons of retains/releases
into these sorts of blocks. One one test case, it increased the amount of raw
instructions by 2-3 orders of magnitude.

We used to implement this in ARCSequenceOpts when it did code motion. When code
motion was stripped out of ARCSequenceOpts and ARCCodeMotion was implemented,
this was not implemented for some reason yielding this regression.

NOTE: If one reads this PR there is "retain" trimming code as well as usage of
ProgramTerminationAnalysis. The reason why I implemented the code in this way is
that tThe program termination analysis allows us to avoid inserting retains at
all into fatal error blocks, but it can not handle cases where a fatal error
block has been merged into another block. The trimmer code handles this case and
potential cases where side-effect code is in the fatal error block. On the other
hand, if we just relied on the retain trimming code, we would be inserting a
huge amount of retains just to free them. That is really wasteful from a
performance standpoint given the amount of retains that we can insert here.

rdar://42347024

include/swift/Strings.h

@@ -13,6 +13,9 @@
 #ifndef SWIFT_STRINGS_H
 #define SWIFT_STRINGS_H
 
+#include "swift/Basic/LLVM.h"
+#include "llvm/ADT/StringRef.h"
+
 namespace swift {
 
 /// The extension for serialized modules.
@@ -89,6 +92,8 @@ constexpr static const char BUILTIN_TYPE_NAME_VEC[] = "Builtin.Vec";
 constexpr static const char BUILTIN_TYPE_NAME_SILTOKEN[] = "Builtin.SILToken";
 /// The name of the Builtin type for Word
 constexpr static const char BUILTIN_TYPE_NAME_WORD[] = "Builtin.Word";
+constexpr static StringLiteral SEMANTICS_ARC_PROGRAMTERMINATION_POINT =
+    "arc.programtermination_point";
 } // end namespace swift
 
 #endif // SWIFT_STRINGS_H