Issue Description:

In builds with assertions enabled (such as the nightly macOS Swift toolchains), LLDB regularly hits an assertion failure in TypeSystemSwiftTypeRef::GetEncoding() when printing variables in many common cases. For example, if you create the following file in Xcode:

import Dispatch

public enum MyEnum {
    case good
    case bad
}

public extension DispatchQueue {
    func asyncEC(
        test: MyEnum = .good,
        execute work: @escaping () -> Void
    ) {
        self.async(execute: work)
    }
}

let queue = DispatchQueue(label: "A", attributes: .concurrent)

queue.asyncEC {
    let a = 33
    print(a)
}

and set a breakpoint on the `self.async()` line, building and running the above will lead to an lldb-rpc-server crash due to the failing assertion here. This renders LLDB unusable within Xcode when working with the nightly Swift snapshots and placing breakpoints in areas that trigger this assertion.

The assertion appears to be the result of non-builtin types (such as the MyEnum type above) falling through the switch statement there. The previous implementation of TypeSystemSwiftTypeRef::GetEncoding() (replaced in this commit) simply called SwiftASTContext's getEncoding() which did not have an assertion for types that fell through the switch statement in the same way. It returned a value of `lldb::eEncodingInvalid` for many of those types.

If you remove the assertion on line 2283 in TypeSystemSwiftTypeRef::GetEncoding() and build a toolchain with that version of LLDB within it, lldb-rpc-server no longer crashes in Xcode in the same places and appears to behave properly. However, simply pulling out an assertion is usually not a preferred solution, so there may be a better way to resolve this.