Bring back the previous behavior of call_guest_function_by_name

[jprendes]

This PR brings back the previous behaviour of call_guest_function_by_name, and exposes the new behavioud behind a different name: run call.

Originally I wanted to call the new behaviour call, but that method exists as an alias to call_guest_function_by_name throught Callable trait.
The risk of using the call name is that anyone using the Callable trait would get an (almost) silent change in behaviour (almost because there would be a lint about Callable being unused).
Decided that there's no big risk of anyone using the Callable trait directly other than through the WIT macros, so using call should be fine.

Let me know if anyone prefers a different name.

[dblnz]

LGTM!

[ludfjig]

Looks good to me

[ludfjig]

LGTM. I guess we decided we don't care about the Callable trait?

[jsturtevant]

LGTM. I guess we decided we don't care about the Callable trait?

It looks like we need to provide a way for this to choose the behavior, or we need to break it/keep current behavior

[syntactically]

I am slightly confused by the division of labour between 65ff6ff and 1d74a97. It seems like the former has code that uses the snaphsot member that is perhaps not correct without the changes from the latter?

Is the intention with 796c6c9 to make all the tests call through Callable?

[jprendes]

Is the intention with 796c6c9 to make all the tests call through Callable?

No, I renamed the method from run to call. Callable is not being used in the tests, other than through the macro.

[jprendes]

Let me update the PR description

[syntactically]

No, I renamed the method from run to call. Callable is not being used in the tests, other than through the macro.

How is the name conflict with Callable::call managed?

Do you mind squashing the run rename with the places where each bit of code was introduced as well? It seems a bit silly to have one commit renaming things from call_guest_by_name to run and another doing it back tocall!

[jprendes]

How is the name conflict with Callable::call managed?

If the trait is not on scope, there's no conflict.
If the trait is on scope, doing sox.call, the new method wins over the trait.
If doing Callable::call(&sbox, ...) again there's no conflict, it uses the trait method.
If doing <sbox as Callable>::call, i ha ent tried, but I guess the trait is used.