API, Core: Use Supplier for FileIO on Scan

[nastra]

This PR refactors the Scan API to return Supplier<FileIO> instead of a direct FileIO instance, enabling lazy/deferred initialization of the FileIO. The motivation is to accommodate cases (e.g., REST scans) where FileIO may not be immediately available at scan construction time.

[nastra]

@rdblue looks like this is an API-breaking change unfortunately. This used to be protected FileIO in 1.10.x.
A viable workaround would be to use fileIO() (or some other naming) at the API level and deprecate and not touch io() here. This can be seen in commit a7e24f2

[nastra]

@rdblue we could consider removing this check, wdyt?

[amogh-jahagirdar]

I do feel like there's an argument that we should still keep the check. The Supplier return type indicates to a caller that they need to think about when to invoke get but if the caller does invoke get prematurely, I think it's best to throw rather than return null.

[amogh-jahagirdar]

This looks good to me, thank you @nastra

[amogh-jahagirdar]

I do feel like there's an argument that we should still keep the check. The Supplier return type indicates to a caller that they need to think about when to invoke get but if the caller does invoke get prematurely, I think it's best to throw rather than return null.