* define new standardized event kind for voting polls
## Poll format (RFC)
Should a poll be self-contained in a single event (including its voting options) or be a parent event (#0) with separate (but linked) child voting option events (#1, #2, #3, #n), each referencing the parent poll event?
#### Self-contained poll event
* Pros:
* likely results in better UX by providing compact, widget-style notes immediately recognizable as unique poll type
* promotes more uniform implementation across clients
* Cons:
* increased poll event complexity, owing to internally nested voting options (each necessarily containing their own zap requirements)
* potentially increased difficulty of client implementation
#### Single parent poll event with linked child voting option events
* Pros:
* better alignment with existing event (specifically zap) structures
* potential for backward compatibility with clients uncompliant with polling events, i.e. non-compliant clients could handle poll event chains same as existing threads
* possibly simplifies implementation by clients?
* Cons:
* introduces possibility for fragmentation of polls, e.g. separation or loss of child voting options
* increased potential for non-uniform implementation of polling UI/UX across clients
