Do not expose Crystal::System::FileInfo in File.info?

[HertzDevil]

Resolves #7685.

[sdogruyol]

Thanks @HertzDevil 🙏

[straight-shoota]

What's the point of having a separate Crystal::System::FileInfo type, though? Its API ist just exactly wrapped in File::Info. The only platform-specific aspects are the method implementations and the constructors. The latter can be made :nodoc: and we could just use File::Info directly instead of an identical system type.

[ftarulla]

Hey @HertzDevil!
Today I mentioned this PR to @beta-ziliani and @straight-shoota.

My understanding after reading this PR and talking to them is that the main problem can be summarized as follows: we need to define the FileInfo API and then we need some platform-specific implementations.

In the current implementation we use inheritance: abstract struct Info would be the API, then leaving its implementation to Crystal::System::FileInfo < ::File::Info (both in unix and win32)
In the proposed solution in this PR, we use composition and so we end up with struct Info and Crystal::System::FileInfo.

A simpler solution (that follows @straight-shoota comment) would be to have some kind of "template class" with the common implementation and also defining the API (File::Info). Then each platform implementation would add the platform-specific methods.

An example of this pattern is the implementation of Socket:

# socket.cr
class Socket < IO
  include Crystal::System::Socket
  ...
  def initialize(...)
    ...
    fd = create_handle(family, type, protocol, blocking)
    ...
  end
end

The implementation of create_handle is platform-specific:

# crystal/system/unix/socket.cr
module Crystal::System::Socket
  private def create_handle(family, type, protocol, blocking) : Handle
    ...
  end
end

Note: The Socket implementation uses modules which I think it won't be necessary in this case.

I know it takes a different approach but would you like to implement the solution I just described?