WIP: Use string as the internal representation and allow an associated multibase.

[kevina]

This is an alternative to #64 to explore the design space.

The main advantage of this is that it does not break any existing code.

This might also perform a little better, but I image it will be negligible.

[Stebalien]

As I've stated before, mixing representation with data is almost never something one should do.

1. We won't be able to use CIDs directly in maps. Being able to iterate over a map with CIDs and values would be really nice. If users do do this, they'll lose the multibase information.
2. Not all representations will be able to conserve the multibase. If the user gives me a set of CIDs and I pack them into an IPLD object, they'll lose the base.
3. It's fixing a UX problem by threading display information throughout the program. From a design standpoint, that's just icky.

[kevina]

@Stebalien both (1) and (2) are fine. If the information is lost that's okay the idea was to preserve it when possible.

For (3) we will have to agree to disagree. As I see it it is threading through optional metadata that just "goes along for the ride".

However, I can see how this add complexity and don't plan to push it.

[kevina]

Closing, as we are going with a pure string representation. Please don't delete the branch.