Support unmarshalling SDP containing unknown attributes or values

[babolivier]

Summary

Add a variant of Unmarshal() that doesn't return an error if an attribute or value is unknown.

Motivation

Some custom implementations might want to use their own custom attributes, or custom values in some of these attributes (e.g. a custom bandwidth type in a b= attribute), that their clients have extra logic to decode. Currently, Unmarshal() returns a syntax error if such attribute or value is found in the session description; it would be great to have a variant of that function which would add any attribute to the Attributes field of the session or media description and not return an error if it fails to recognise the attribute or a value in its content.

[Sean-Der]

I am worried if we make a permissive path it may result in bad SDPs getting through the non-permissive path.

What do you think of maybe providing a tokenizer so that users can go line by line themselves. That way we don't have two Unmarshal functions. Users that want to take the risk can go do it, but not complicate the API maybe?

[babolivier]

I am worried if we make a permissive path it may result in bad SDPs getting through the non-permissive path.

From my point of view, it really depends on what you want to do when parsing SDP. For instance, what I'm working with right now only cares about getting a Go structure that it can manipulate (e.g. append candidates retrieved separately) and then marshal into a string it can pass on; in which case the extra validation is nice to have (as long as it doesn't get in the way, e.g. with bandwidth types) but not what I'm primarily looking for.

To be perfectly honest I've suggested to have a second Unmarshal function because that's the only idea I had (and didn't have a lot of time to write this issue) but other solutions might be better as long as they can serve the same goal.