base58 encoding should happen in left-to-right order about rust-bitcoin

[sgeisler]

After thinking about this problem more thoroughly I suspect that you can't do arbitrary base conversions in constant space. For the first character one had to calculate the number represented by the byte string divided by 58^n which doesn't seem doable in constant space (and reasonable time). I spoke with @sipa about that and he shares my doubt, but he also suggested a solution to avoid allocations:

We could just decide on a maximum expected length (which should be possible for our use case) and use a (stack) array of that size.

[apoelstra]

I think that's reasonable. I think the longest thing we might base58-encode are BIP32 xpubs which are 78 bytes.. we could go way past that, to be certain, but probably a couple hundred bytes are fine (and maybe we would fall back to the allocation-based method rather than failing if we exceeded this)

[sgeisler]

If we want to keep our base58 encoding functionality public then we probably should fallback to using a vector, panicking public interfaces aren't nice. And I guess there are downstream users of this API :/ (although I don't really see a use case that would concern our user base since all bitcoin related usages of base58 are implemented in rust-bitcoin).

[apoelstra]

Well, Elements' confidential addresses use base58 encoding for example...it happens that they're shorter (64 bytes) than an xpub, but they just as easily could've been longer.