[JExtract] Support `typealias`

[rintaro]

public struct Bytes {
  public typealias Element = Int8
  public func append(_ element: Element)
}

Bytes.append(_:) should be translated to void append(java.lang.Byte element)

To do that JExtract should support typealias declaration.

[rintaro]

This should also fix this:

swift-java/Sources/JExtractSwiftLib/SwiftTypes/SwiftKnownModules.swift

Lines 81 to 82 in 7f24d62

	// FIXME: Support 'typealias Void = ()'
	public struct Void {}

[timofeys1]

I am curious if this is the limitation of jextract relying heavily on Swift Syntax? Does this mean Swift Java or Swift Syntax itself would have to reimplement some form of type checking and inference? I imagine Swift Java can't just naively translate a typealias because Java doesn't have a notion of a typealias.

[rintaro]

We do have a basic name-lookup implementation already

swift-java/Sources/JExtractSwiftLib/SwiftTypes/SwiftTypeLookupContext.swift

Lines 31 to 37 in 8cf1829

	/// Perform unqualified type lookup.
	///
	/// - Parameters:
	/// - name: name to lookup
	/// - node: `Syntax` node the lookup happened
	func unqualifiedLookup(name: Identifier, from node: some SyntaxProtocol) throws -> SwiftTypeDeclaration? {

It's far from complete, but it should be sufficient for initial typealias supporting work.

For anything that isn't handled by the current lookup logic, we can file separate issues individually.

[tkrajacic]

I was just going to create a new issue, but I guess this is just as good a place.

Top level typealiases are pretty useful when dealing with properties that are not (yet) bridged to Java:

#if os(Android)
public typealias Amount = Double
#else
public typealias Amount = Decimal
#endif

See tkrajacic/swift-android-examples@b42c178

This doesn't work yet, but would be pretty convenient.