Community - Add voting power and vote estimate

[eonwarped]

Adds fetching the current logged in account and fetching of reward fund to show voting power and vote estimates.

Modifies the pending payout computation as well, which may be slightly confusing in the current state as it flips between cached and computed values. Can be mitigated by either not computing on the fly and only using it for vote estimate or fetching reward fund earlier in the flow (on getState).

I also am not 100% sure how to explain differences in computed vs freshly updated posts at the moment when testing. Thought it might be precision but I double-checked using bignums anyway without much change.

In any case, this may or may not be desirable as is, will leave as reference at the least and make any suggested changes if this feature is desired.

[roadscape]

This information is useful to have in the UI, but there are several concerns:

1. Most of this logic would be better suited for a backend
2. Existing voting/payout components need redesign and best to keep them as simple as possible for now
3. Current working branch is bridge-api-dev and has non-trivial changes to Voting/Payout elements (frontend and backend)

[eonwarped]

1. Estimates in the backend will be harder for handling new votes. I think there's no way around just computing it based on the reward data available. However, as noted in other chats, there are issues with these reward parameters being out of sync with backend estimates already, and for some odd reason the current computations are off by a significant amount at higher rshares, which I still have not figured out if it's just staleness or what) 2/3. This is fine, I think the wiring can be reshuffled without too much hassle, however the newer design pattern is.

[roadscape]

The main concern is that this change and adds complexity at a time when we're transitioning more logic to the backend and culling the number of required API calls. I suggest we hold until dev branch is merged to master.