Replace Pin.depth with Pin.mode string enum

[lidel]

See also for alternative simpler boolean version.

This PR removes ambiguity of depth: -1 for recursive pins (cc @ achingbrain) and enables arbitrary modes of pinning to be added in the future.

I included the third type named 'pinset', which could represent a well-known format for storing all local pins (cc @aschmahmann, we discussed something like this last week), but we can remove it if its not feasible atm.

cc @obo20

[achingbrain]

I think depth?=n is better than mode=direct|recursive, I just didn't want depth: -1 because it's nonsensical.

depth also enables partial pinning which allows sharding massive datasets.

pinset as an enum value doesn't seem right to me either - if we need some way of grouping pins (e.g. all local pins as above), let's have multiple pinsets, and give them names.

[obo20]

Similarly to how pinning services handle depth (they don't) I'm pretty sure all pinning services (including Pinata) assume every pin is recursive in nature and I'm not aware of any service that specifically allows for direct pins. This may be another filter that isn't needed.

[lidel]

Thanks! Sounds like we can close this in favor of (optional) https://github.com/ipfs/pinning-services-api-spec/pull/19