Shared / Multisig / Sharded IPNS Keys

This is a placeholder issue for tracking this topic.

## Why

Publishing updates is important.
Being able to do it without dependency on censorable DNS, or paying for Gas to some blockchain grows the pie of use cases IPNS could serve.

Would be beneficial to the IPFS ecosystem if
- https://specs.ipfs.tech/ipns/ includes a golden path spec that is known to work, and has been reviewed by more than one dev
- devs had built-in support and examples in some reference libraries that work with [boxo/ipns (go)](https://github.com/ipfs/boxo/tree/main/ipns) or [js-ipns](https://github.com/ipfs/js-ipns)
- this allows for people to build things that resolve fine in regular clients, without waiting for implementations like Kubo

## How (Feature Set)

TBD, topics to discuss:
- could it work with existing spec and legacy clients? (do not require custom signature)
- is the goal to have N sub-keys (shards) and only M required for publishing (M<=N, both >=1), or something else?
- details tbd, the most common ask has been to require min. 2 sigs to ensure peer review before publishing IPNS Record update
- is there a way to replace shards with new ones?

## TODO

- [ ] gather prior art from community :point_left: **we are here**
- please comment on this issue, ideally with working code or spec draft
- an ideal MVP is to have a solution for the default key type (currently ED25519) what works with legacy IPNS clients (only publisher needs to support multisig)
- If you feel confident in your solution, and want to discuss technical details, proposing [IPIP](https://specs.ipfs.tech/meta/ipip-process/) in a PR is appreciated
- [ ] decide on feature set
- [ ] find a champion to open a PR with [IPIP](https://specs.ipfs.tech/meta/ipip-process/)
- [ ] wait for https://github.com/ipfs/specs/issues/376 as it needs to happen before anything else

## Prior Art

- [threshold-ipns](https://github.com/TheFrozenFire/threshold-ipns/blob/master/main.go) by @TheFrozenFire (ed25519 with threshold shards)