Fix generateResourceAccessor WASI regression

[MaxDesiatov]

Motivation:

Changes in #3463 broke resource accessor generation when building WASI/WebAssembly projects.

Modifications:

generateResourceAccessor now checks if destination triple is targeting WASI, and uses old behavior from Swift 5.4 that works on this platform.

Result:

Projects targeting WASI that contain resources no longer fail to build.

[MaxDesiatov]

@swift-ci please smoke test

[MaxDesiatov]

@swift-ci please smoke test

[neonichu]

Do we need to differentiate on path vs. URL for WASI? I think right now it's easy to think that's the main change between the two code paths, when actually the difference is that we ask running compile vs. runtime.

[tomerd]

pending @neonichu point about runtime behavior

[MaxDesiatov]

I do prefer compile-time here for WASI, there's no benefit in evaluating this at runtime, especially as Bundle support in WASI Foundation is partial. We expect all resource paths to evaluate to /\(resourceBundleName)/\(resourcePath), which allows us to pass this path to JS functions like fetch directly, or to <img src= HTML attributes. The resources are loaded from the server, and we can't hardcode the host part in the URL. Making URLs relative by starting them with /\(resourceBundleName) makes it work.

CC @kateinoigakukun

[neonichu]

Sounds reasonable to me. I wasn't suggesting to change the behavior, but to change the code to make more clear what's happening, e.g. by adding some comments, so that the next person won't see this as an opportunity to refactor something :)

[MaxDesiatov]

Makes perfect sense, I'm adding a comment rn

[MaxDesiatov]

@swift-ci please smoke test

[tomerd]

@neonichu I feel seen