Swift has more strict type system than Objective-C. For example,
protocol conformance must not be redundant[1]. Also, Both FlutterError
and Swift.Error are public, extension `FlutterError` to `Swift.Error`
is also public. If someone create a such extension in the plugin
code, Flutter app can't create a such extension in the app code, which
forces Plugin developers to use Objective-C when they want to use
pigeon, instead of Swift.

To avoid this issue, this change makes pigeon to use another error
type, named PigeonError, instead of FlutterError. By declaring
PigeonError as internal visibility, their existence won't make
compilation error even if PigeonError is declared in the app code.

[1] https://docs.swift.org/swift-book/documentation/the-swift-programming-language/declarations/#Protocol-Conformance-Must-Not-Be-Redundant

While PigeonError is defined as an internal visibility, so different
modules don't have problems with the same class name, it's still
troublesome to have it in the generated code if users call pigeon
multiple times in the same module.
To solve this problem, add a new option, `swift_emit_error_class`,
to control whether to emit the PigeonError class in the generated
Swift code. The default value is true, which means the PigeonError
class will be emitted as before.

Apparently, when checking `pod lib lint`, other generated files might be
missing.

And add a test for the new option.

Like Kotlin, to not have a conflict with the same name of the error
class, we should emit different names for each error class.

This is because `pod lib lint` runs without the generated code.
Therefore, CoreTests.gen.swift must be able to compile on its own.

…pigeon-swift-error

And replace existing usage of FlutterError.