Profit Sharing - supplement

I would like to supplement the existing Profit Sharing proposal #1172 with this use case.

**User Story**

let's assume I'm one of the leaders in a certain community. Leaders in various events issue different types of tokens (e.g. such as {living example →} BROWNIE.PTS, STEALTH, VIRGROW, SHAREBITS, ... ) and allocate them to different users according to certain criteria.
Let's assume that after a year of community existence I would like to pay certain users bonuses for their activity. This activity is reflected in the number and type of tokens held within the community. For this reason I want to send :

- 50% token A (e.g. bitUSD or any other private UIA), to users who have token B (pro-rata)
- 30% token A, to users who have token C, **for less than 60 days**
- 20% token A, to users who have token D, **for more than 365 days**

**Additional Context **

We have a platform for creating tokens and we can create a lot of types of tokens.
Let's imagine that suddenly users want to create their own tokens - they do it because they can, but what can they do with them in the GUI now?
They can send or issue a token to one account at a time.
_(I am aware that larger organizations can code more activities themselves)_

It seems to me that this is not enough, and the first **two things I miss are**:

1) Profit sharing (pro-rata), the community sees this need, that's why we've had BSIP (19 & 20 & #1172) for it.

2) Sending tokens to many recipients, e.g. in the form of defined account lists in some files (maybe csv)

_UI related_
https://github.com/bitshares/bitshares-ui/issues/1249

The name **BitShares** immediately brings me some associations that ignite my imagination exactly in this kind of use cases. The ICO era (I mean ETH in 2017) would be different if we had such abilities from the beginning, but it's not over yet and better late than never. Let's create Token Studio

**Impacts**
- [ ] maybe a new token predicate is need it associated with its maturity
- [ ] API (the application programming interface)
- [ ] CLI (the command line wallet)
- [ ] P2P (the peer-to-peer network for transaction/block propagation)
- [ ] Performance (system or user efficiency, etc.)
- [ ] Protocol (the blockchain logic, consensus, validation, etc.)
- [ ] UX (the User Experience)

Start by reviewing proposal #1172 and BSIPs 19 and 20 to understand the existing profit-sharing scope. Then compare the requested token-age rules and batch recipient support with the linked BitShares UI issue #1249, and identify whether the work belongs in the protocol, API, CLI, or UX. Done requires an agreed design and implementation scope; this issue does not name files or tests.

Written by the indexing model from the issue text.