[5.5-05142021][Serialization] Prevent crash when inherited types are invalid

[bnbarham]

Cherry-picks #37441 (the main change) and #37519 (small test change to prevent conflicts between main and 5.5).

For most cases this is just an assert, but for protocols it can end up being a crash due to the extra check it performs (if (element.getType()->is<ProtocolType>())).

---

When compiling with allow errors, it's possible to have invalid
inherited types - both null and ErrorType.

Cleaned up the tests a little - moved the majority of
Frontend/allow-errors.swift into separate files in
Serialization/AllowErrors and use split_file.py instead of #defines.

Resolves rdar://78048470

[bnbarham]

@swift-ci please test

[bnbarham]

@swift-ci please nominate

Explanation:
Background indexing now has its own build arena, where source is compiled with an option to allow outputting the .swiftmodule regardless of compiler errors. In this mode, the following code will result in the inherited types being null rather than an ErrorType:

extension undefined {
  class Anything: undefined {...}
...
}

For class/struct/enum, this only causes an assertion and release builds are unaffected. Protocols, however, will end up generating a SIGSEGV. While it's invalid to define a protocol within an extension, it wouldn't be an uncommon case to hit while editing, ie.

extension CurrentlyAdding {
...

protocol AlreadyExists: undefined {...}

Radar/SR Issue: rdar://78048470

Risk: Low. This change adds null checks before using the inherited type.

Testing: Added new test cases to check for these cases (protocol/class/struct/enum with an undefined parent in an undefined extension).

[swift-ci]

Build failed
Swift Test Linux Platform
Git Sha - a03b891