Support for multiple tick periods (timers). #72

Currently only one conceptual timer can be configured by filter instance by calling proxy_set_tick_period_milliseconds(). It implies that if multiple timers are required (i.e. multiple distinct tick_period's), the user has the responsibility to define an algorithm to decide the ideal tick period to cover all distinct tick_period's and writing the logic to demultiplex proxy_on_tick() on distinct listeners. Also the tick period lifecycle (i.e. when to erase or override the current tick_period) must be explicitly managed taking care of the multiple listeners. It seems a lot of boilerplate for a filter and looks more like an OS/platform responsibility.
WASI clocks covers that use case, but it is probably far from what proxy-wasm can provide today, since it requires complex polling types that do not fit with the proxy-wasm event-loop style.
A more conservative approach may be to introduce a third parameter return_timer_id to proxy_set_tick_period_milliseconds() to return an identifier for the timer:

proxy_set_tick_period_milliseconds

• params:
  • i32 (uint32_t) tick_period
  • i32 (uint32_t *) return_timer_id
• returns:
  • i32 ([proxy_status_t]) status

Additionally proxy_on_tick() could receive the timer_id as second parameter:

proxy_on_tick

• params:
  • i32 (uint32_t) plugin_context_id
  • i32 (uint32_t ) timer_id
• returns:
  • none

With this API the user registers a new tick_period with proxy_set_tick_period_milliseconds(), receives a timer_id, and waits for the next proxy_on_tick() related to that timer_id.