Pinning a unixfs path doesn't pin the required blocks.

### Checklist

- [X] This is a bug report, not a question. Ask questions on [discuss.ipfs.io](https://discuss.ipfs.io).
- [X] I have searched on the [issue tracker](https://github.com/ipfs/go-ipfs/issues?q=is%3Aissue) for my bug.
- [X] I am running the latest [go-ipfs version](https://dist.ipfs.io/#go-ipfs) or have an issue updating.

### Installation method

built from source

### Version

```Text
go-ipfs version: 0.12.0-rc1-8a88718ea
Repo version: 12
System version: amd64/linux
Golang version: go1.17.5
```

### Config

```json
N/A
```

### Description

If you do:
```
ipfs pin add Qmfoo/a.txt
```
I belive you are safe to assume that the path `Qmfoo/a.txt` is always gonna work.
However that not true because what happen in practice is that it resolves `Qmfoo/a.txt` at pinning time to `a.txt`'s root and pin a's root recursively.
That mean the block (or blocks if that a sharded directory) `Qmfoo` can be lost, meaning you can never do `Qmfoo/a.txt` to a's root path anymore.

I belive this should pin a minimal provable traversal from `Qmfoo` to a's root, including the `Qmfoo` block*s*. In case of `Qmfoo/b/a.txt`, it would select `Qmfoo` and `Qmfoo/b`. And then blew up to recursive pinning until the last path item is reached.

Note this minimal provable then recursive traversal is usefull in many other situations, such as gateways that would serve `.car` files and clients trustlessly verifying the gateway response (note in this example the gateway could still censor files, but at least not change them).

Altho I've not tested it, I belive very likely that this also applies to other things that resolve the true root and then follow recursively such as `ipfs dag export Qmfoo/a.txt` (and if `ipfs dag export` only accepts direct CIDs, I belive minimal provable traversal of paths should be a feature supported).

### Reported by:

This has been reported by someone on the IPFS discord which I forgot about (*sorry*).