The following race may happen if ubf_timer_destroy calls
timer_delete before ubf_timer_disarm gets called from
a different thread.  Consider the following timelines:

  ubf_timer_destroy                    | ubf_timer_disarm
  -------------------------------------+-----------------------------
                                       | CAS(ARM => DISARM)
  CAS(DISARM => DEAD)                  |
  timer_delete                         |
                                       | timer_settime(disarm)

Another option may be to add an intermediate "RTIMER_DISARMING"
state to the transition, but I figure the EINVAL check is
simpler and less intrusive code-wise.

cf. http://ci.rvm.jp/results/trunk-iseq_binary@silicon-docker/1545794

git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66457 b2dd03c8-39d4-4d8f-98ff-823fe69b080e