Fix WIT extractor ignoring world-level functions

[itowlson]

The WIT extractor currently doesn't handle function imports, where a dep's world exports a function (instead/as well as an interface), and the function is named in the spin.toml dep.

This fixes that.

Thanks to @fibonacci1729 for flagging this bug, and for showing me how to do world-function imports in Spin - now I know what the mystery Plain case is for!

@fibonacci1729 The way I ended up doing this was yoinking the importised function into the root world (rather than including the world as we originally discussed). This just worked out easier with the existing code.

[fibonacci1729]

Thanks! This is looking good. The only concern I have is that we aren't remapping the cloned function types before inserting into the aggregating world.

The test passes because it only uses string and bool (primitive types that don't carry TypeIds). A test with a function like is-curse: func(s: my-record) -> bool would expose this. Would you mind adding a test to verify this?

If this ^ is the case, i can imagine 2 possible fixes:

1. After merge, remap the TypeIds inside the function's params/result using remap.map_type().
2. Extract the function after merge from the aggregating resolve (using remap.map_world() to locate the importised world), avoiding stale IDs entirely.

[itowlson]

Good catch, thanks. I'm blundering in the dark here a bit, but if I can't figure it out I will send up the Bat-signal.

[itowlson]

I spent some time on the user-defined type problem, but there are some complicated shenanigans involved in getting the necessary use into the world, and then rewiring the function to use the use-d form, and then fretting about options and results and lists and oh my. I did bounce it all off Alex, and he suggested some ways forward, but we still hit a dead end. Thank you Alex for all your time and help!

We were therefore faced with a choice of pulling the feature, or deferring this case and instead giving a clear error when it arose. The proposed approach, which this PR now includes, is to retain the feature with a known limitation on custom records in world level functions. If a user imports such a function, they will get this error:

comp-consumer-build-rs-test: Spin can't generate imports for `bibbly-bibble` because it is a world-level function with a non-primitive parameter or result type

It would be good to revisit this when folks who know this stuff better than I do have more bandwidth for it, but we can be guided by user need on prioritising that.

[fibonacci1729]

@itowlson i pushed some code to my branch/fork that i think addresses the world level difficulties.

The code adds a world_type_imports helper to collect WorldItem::Type entries from the importized world and copies those type entries (remapped) into the aggregating world before the function. It has some simple tests but it would be great if you have a trickier example to stress test with.

Feel free to take it or leave!