Symbolic links in KBFS should be restricted to a safer set

I would encourage the Keybase developers to restrict what symlinks can be written to KBFS as a security precaution: Symlinks should only point outwards from more private areas to less private ones; from places definitely under the user's control to places possibly not under their control.

From the [KBFS docs](https://keybase.io/docs/kbfs/understanding_kbfs#symbolic-links-can-lead-outside-a-tlf), a rationale for allowing them:

> The Keybase client allows symbolic links that lead outside a TLF [Top Level Folder]. This is by design, and we envision a variety of great use cases:
> - a subfolder of your public folder, where you link to friends' public folders you endorse
> - storing private links to all your favorite private folders
> - a link entirely outside KBFS to another global filesystem you endorse. For example, to something in IPFS.

The text then goes on to describe various situations in which a user could be tricked into revealing private files.

Incautiously handled symlinks are the cause of a great number of security issues. I like to watch the security updates as they come in to my OS. The top type of problem is of course unsafe memory operations (buffer overflows and whatnot), but a close follower is symlink mismanagement. People are notoriously bad at handling symlinks safely. "Don't do that then" has a pretty bad track record in this area.

Here's a sample proposal, although I would entertain many variations on it:
- Public objects may only link to other public objects
- Shared private objects may only link to public objects and objects in the same TLF
- Unshared private objects (only one identity, e.g. `chris`) may ~~additionally link to shared private objects containing the same identity, e.g. `chris,max`.~~ link anywhere
- Continue to document that symlinks may pop up anywhere in KBFS, to anywhere (don't rely on the above restrictions)

This would avoid situations where an attacker is able to place a symlink to OS files, user data files, or private KBFS objects on the victim's computer as part of an attack based on mistaken file identity. Further consideration might reveal other combinations of source and target that are safe, such as the aforementioned links to IPFS.

Start with the KBFS documentation section on symbolic links and its listed security scenarios. Review the proposed public, shared-private, and unshared-private source/target rules, then determine the implementation entry point; done means an agreed restriction policy and matching documentation that still warns users not to rely on it.

Written by the indexing model from the issue text.