Telemetry: click count per menu option

[lidel]

Currently, the telemetry (#1117 ) has low value.
IIUC only "views" are tracked, and that means only "optiona" and "quick import" features are tracked (because they own HTML page), but nothing else.

No way to reason about feature usefullness without having the full picture.
We need to know which features accessible via browser action menu are the mostly used.

If we are gathering telemetry, let's make it worth the effort.
We need to how many times each button was clicked. Every clickable item on the below screenshot should bump its click count:

[SgtPooki]

This needs to come after the intercepted URLs metrics: #1127

[SgtPooki]

@lidel we're currently taking a more holistic approach with telemetry. To that end, the first step is proving our most used product to help prioritization efforts. The existing metrics helps us to answer that question, and gives us a baseline for any future changes. The basic questions such as:

1. did adding/removing X feature increase/decrease users?
2. what is our usage cycle throughout a week/month/quarter?

and other things talked about in ipfs/ipfs-gui#126. If you have additional questions or concerns regarding things we should be gathering, I think that would be the right place.

Regarding feature metrics specifically for ipfs-companion, and the telemetry added in #1117 being of low value, I disagree. You propose adding click metrics to the browser action view. I agree that insight into feature usage of our apps is important, but if we determine that 90% of users don't use the browser action, are click metrics as important?

Additionally, many metrics were added to webui and desktop previously without much in the way of analytics being done on them. I want us to stay as far from that approach as possible. If we add metrics for a click/view, we need to think thoroughly through:

1. why they're being added
2. when those metrics might be removed
3. how, and how often, we're going to monitor the values
4. what decisions we might change based on the values of those metrics
5. at what values we might make certain decisions.

Right now, we're missing a few of the key pieces necessary to justify this work over our other work, so I'm going to reduce the priority

[lidel]

Ack on priorities, approach is sensible.
We can revisit this when a redesign on this view is on the table again.