**Fix Race Condition in Main Loop**

This commit addresses a race condition in the main loop involving
`pthread_cond_wait()` and `pthread_cond_signal()`. The issue occurs
in multithreaded applications using condition variables in the
main loop, as follows:

**Previous code:**

```C
while (quit != 1) {
  oc_clock_time_t next_event = oc_main_poll_v1();
  pthread_mutex_lock(&g_mutex);
  ...
  pthread_cond_wait(&g_cv, &g_mutex);
  ...
  pthread_mutex_unlock(&g_mutex);
}
```

```C
void signal_event_loop(void) {
  pthread_cond_signal(&g_cv);
}
```

The problem arises when:

1. The `oc_main_poll_v1()` call in the main thread is completed.
2. The main thread is paused.
3. A worker thread requests polling and calls `signal_event_loop()`,
expecting to wake up the main thread for `oc_main_poll_v1`.
4. The worker thread is paused.
5. The main thread resumes execution.
6. `pthread_cond_wait` is called, causing the main loop to wait on
the condition variable, missing the requested polling from the
worker thread.

To resolve this issue, we introduced additional synchronization. We
extended the public API with a new function, `bool oc_main_needs_poll()`,
which returns `true` if polling was requested but not yet processed.
By using `oc_main_needs_poll()` and correctly synchronizing
`pthread_cond_wait` and `pthread_cond_signal`, we prevent the race
condition.

**Updated Code:**

```C
while (quit != 1) {
  oc_clock_time_t next_event = oc_main_poll_v1();
  pthread_mutex_lock(&g_mutex);
  if (oc_main_needs_poll()) {
    pthread_mutex_unlock(&g_mutex);
    continue;
  }
  ...
  pthread_cond_wait(&g_cv, &g_mutex);
  ...
  pthread_mutex_unlock(&g_mutex);
}
```

```C
void signal_event_loop(void) {
  pthread_mutex_lock(&g_mutex);
  pthread_cond_signal(&g_cv);
  pthread_mutex_unlock(&g_mutex);
}
```

This change ensures correct synchronization in the main loop,
preventing race conditions when waiting for polling requests.