Provide API for other browser extensions

[Interesting idea for WebExtension ecosystem](https://discourse.mozilla.org/t/extensions-providing-apis-to-other-extensions/21555?u=lidel):

> I think extensions working together by providing APIs to each other is a really cool thing. APIs can either be a [`runtime.onMessageExternal`](https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/runtime/onMessageExternal) (or [`onConnectExternal`](https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/runtime/onConnectExternal)) protocol or a global injected into a website that other extensions and user scripts can interact with to augment functionality.
>
> I’ve started a list with documented APIs (I know of a few more, but no documentation for them, at least yet): https://github.com/freaktechnik/awesome-extension-apis

Quick brain dump:
- In theory, ipfs-companion could provide an API for other extensions
- additional incentive for installing the add-on
- decrease complexity of other extensions
- As a PoC we could provide a small sub-set of `interface-ipfs-core`
- eg. read-only `files.get`, `swarm.peers` etc.
- think about security considerations
(eg. should we avoid mutable actions until we have some kind of ACL?)
- Other extensions should be able to use the built-in management API to check if the ipfs-companion is installed, before request is sent, or just implement correct error handling

#### Potential client extensions
- https://addons.mozilla.org/en-US/firefox/addon/wayback-machine_new/ (https://dweb.archive.org/)
- https://addons.mozilla.org/en-US/firefox/addon/2read/

No repository files, tests, or entry points are identified. Start by reviewing the linked WebExtension external messaging APIs and the proposed interface-ipfs-core subset, then define the security and ACL requirements. Done means an agreed API design and a scoped proof of concept, including how client extensions detect and handle the companion.

Written by the indexing model from the issue text.