Add MarshalerWithContext and UnmarshalerWithContext interfaces

[mugabe]

No description provided.

[ccoVeille]

I feel like this is PR is good, but we might need to find a better way to address the issue it tries to fix.

• #187

I'm not expecting you to work on a new implementation. I'm sure you can.
I'm not looking for it for now.

I feel like the discussion should continue in the issue you opened rather than here in the code

[ccoVeille]

Having a context stored in a struct is an anti pattern.

For me, there is a problem here.

But it might be needed if we don't want a PR that breaks everything and methods signature.

[ingydotnet]

To me it feels like this would best be address with a Context option in our upcoming Options system.

[ingydotnet]

I'd like to see how this could be introduced as a v4 plugin. See #212 for an intro..

The idea with plugins is that they provide generic hooks into the processing.
If Context was a plugin, go-yaml would offer an implementation package to use for it, but then any 3rd party could make something potentially better.

Plugins are an abstraction that don't lock us into specific implementations.

Comments are a good example. There is no way to do comments in a way that is right for everyone. go-yaml might offer 2 or 3 plugins for comment strategies, but certainly there will be many more.

[ingydotnet]

I will state that I am currently interested in having context be a Plugin type.

I'm not keen on supporting ContextLoad et al.
It obviously bloats the API, but more importantly to me it locks us into a single Context strategy.

One of the biggest points of Plugins is to allow multiple strategies for any given topic.
And strategies NOT implemented by us!

As long as you follow a plugin type's API, you can use any code you want to satisfy it.

I'll report back when the Plugin API code has been written and merged.