Consider adding dedicated functions for serializing/deserializing PortableDID's

[KendallWeihe]

Originally spurred from discourse here #77 (comment)

// PortableDID is a serializable BearerDID.

PortableDID's being serializable, and you know, intending to be portable, it may be good practice to offer dedicated functions for serializing/deserializing

This would immediately be applicable to the "indentation" component of this feature #64

Now we are faced with the decision's...

• "Serialize"/"Deserialize"
• "Encode"/"Decode"
• "Marshal"/"Unmarshal"
• "ToString()" or "Stringify()"/"FromString()" or "Parse()"

I think it's safe to assume we would want to/from strings, but what about byte arrays?

[KendallWeihe]

I'm just going to stub this in for now because as I think this through it may be a bit more of a can of worms than just adding two new functions. Here is where I land right now

func (d PortableDID) ToString() (string, error) {

}

func ParsePortableDID(portableDID string) (PortableDID, error) {

}

And then ToString() would have an options parameter to offer indentation (and whitespace?) features... anything else...?

---

More thoughtful exploration...

1. Only implement string support for now, byte array can come later if warranted
2. I think I would veer away from "marshal" language as we have pointed out that language being more appropriate at networking-adjacent functionality. I would also veer away from "encode" language as that's more appropriate to me in the case of having something like a base64 (or choose whichever you want) encoding requirement. Though we haven't been consistent on these both of these points. So that leaves us with "serialize" or "string" language. We don't have any history of "serialization" language, so although it makes sense to me, it would be new.

[tomdaffurn]

Scan() and Value() are useful too for DB serialization. I like String() and Parse() for general purpose