Allow parsing module from any filesystem

[radeksimko]

Summary

This PR introduces two new interfaces to aid with accessing configuration in any "abstract" filesystem, such as in-memory FS which is used by the language server. In LSP the server should not read files from disk if there is copy in memory (as sent by the client).

type FS interface {
	Open(name string) (File, error)
	ReadFile(name string) ([]byte, error)
	ReadDir(dirname string) ([]os.FileInfo, error)
}
type File interface {
	Stat() (os.FileInfo, error)
	Read([]byte) (int, error)
	Close() error
}

I created interfaces pretty much identical to the ones recently published in the Go proposal for io/fs. We don't actually need Open nor File, but I believe that adding later anything to an interface is going to be much harder than removing anything. Also assuming that the proposal goes ahead and is implemented like this, it should be fairly easy to just swap the argument types for the stdlib ones and add type aliases.

Two new functions which use this new interface were also introduced:

• LoadModuleFromFilesystem(fs FS, dir string) (*Module, Diagnostics)
  • similar to LoadModule(dir string) (*Module, Diagnostics)
• IsModuleDirOnFilesystem(fs FS, dir string) bool
  • similar to IsModuleDir(dir string) bool

Backwards Compatibility for Existing Consumers

The existing interfaces should work the same as before.

[radeksimko]

This error matches the one from ParseHCLFile: https://github.com/hashicorp/hcl/blob/350d663f3c09e5a6d72ca11cb3250c1ce395bc8f/hclparse/parser.go#L70-L79

There is a small drift from ParseJSONFile in that json.ParseFile first opens the file and reports early diagnostic from there. This difference seems insignificant to me, but I'm open to retrofitting the extra Open call with that extra dedicated diagnostic here if deemed necessary.

[radeksimko]

These original Parse*File methods also provided "cache" of AST for each file which this change effectively removes.

It's just filename-based cache and so in order to get a hit we'd need two duplicate files in a directory, which is unlikely to ever happen anyway, so this change should in that sense be harmless and shouldn't affect performance in any way.

[pselle]

Thanks for including the clarifying comments in the diff! LGTM