Improve FFI behavior for unsupported architectures

[aaronbuchwald]

After #868 we push pre-built binaries to https://github.com/ava-labs/firewood-go , so that golang consumers can use the library directly without compiling firewood locally.

However, if you use an architecture that we don't include a pre-built binary for, those programs will get a linking error.

To improve this behavior, we should instead use build constraints to switch between a correctly functioning version of Firewood and a version that returns a special case error if constructing an instance of firewood on an unsupported architecture.

This ensures that if you are for example using Firewood as an optional backend in AvalancheGo/Coreth, you will get an error only when selecting that option and trying to construct an instance of Firewood rather than causing the program to completely fail to compile.

[aaronbuchwald]

Firewood FFI layer currently exports all concrete types rather than interfaces. To provide a pass through implementation on unsupported architectures, we need to provide two implementations (actual and invalid).

If we keep the exported concrete types, then we need to ensure that the "invalid" implementation replicates those types exactly. I suspect it will be easier to ensure this if we adopt one exported interface and non-exported implementations, so that we can provide a type check for both and be sure that we don't leak any details a consumer might use and break with the unsupported implementation:

var (
	Interface = (*firewood)(nil)
	Interface = (*unsupportedFirewood)(nil)
)

[rkuris]

@JuanLeon2 please look into whether we can get the avalanchego stuff to not use windoze

[aaronbuchwald]

Discussed in person yesterday and we are opting to solve this a different way for now. We are planning to remove explicit windows support in Coreth and AvalancheGo.

Additionally, @rkuris pointed out that switching to an interface may pay a small performance penalty. Since we already use Coreth to implement the triedb interface within Coreth and are not currently required to support other use cases that require windows, we will plan to handle unsupported architectures at the call-site within Coreth rather than in the Firewood FFI layer itself.

This means that where Coreth currently wraps the Firewood FFI (ava-labs/coreth#959) to implement the TrieDB interface, if running on WIndows, it will check if running on windows and return an error when attempting to construct the database.

refs for removing Windows support in AvalancheGo:

• chore: move windows from tier 3 to unsupported avalanchego#4031
• chore: fully remove windows support special cases avalanchego#4032