Use fully qualified path to types in generated code

[tpoliaw]

If user code has a type alias (or custom type) called Result or Option etc,
this would be used instead of the intended standard library types causing
surprising compile errors from generated code.

Using the fully qualified path allows the generated code to be isolated
from user types.

Fixes #1194

[tpoliaw]

Looking at this again there are many other cases that could fail in the same way (Some, None, Send, Sync etc). I will try and go through and add the paths for the other types but for traits/types that are available in both std and core, is there a preference for one over the other?

[tpoliaw]

This worked before but I changed it to make it more clear that the types are correctly qualified. I spent quite a while trying to track down an expected identifier, found :: error caused by the doubly qualified path (::std::option::Option::std::option::Option::Some(...) after only changing the other line.

Happy to revert if preferred.

[LegNeato]

Looking at this again there are many other cases that could fail in the same way (Some, None, Send, Sync etc). I will try and go through and add the paths for the other types but for traits/types that are available in both std and core, is there a preference for one over the other?

The preference would be core over std where possible. Last I looked we still build on no_std.

[tpoliaw]

Last I looked we still build on no_std

Does that include using the derived code? There are several instances of things like String and Box floating around that presumably require std.

I will update the changes in this PR to use core though. Should existing references to ::std::* in derives be updated at the same time?

[LegNeato]

Sorry, I was mistaken...I got my wires crossed with wasm

[LegNeato]

Awesome, thanks!