fix(lock) handle all resty.lock failure modes

[flrgh]

This fixes some issues with the business logic used when calling a mutexed function:

1. The result of pcall(resty_lock, lock_obj, key) was checked to ensure no exception was raised, but the actual result of acquiring a lock was never checked, so functions could be executed without holding a valid lock
2. The conditions that would cause a mutexed function to be retried in a timer were a little bit broad, which could lead to scheduling more timers than we really want to

Both run_mutexed_fn and run_fn_locked_target_list shared much of the same logic, so I factored it out into a common run_locked function which contains several behavioral changes:

1. resty.lock:lock() is no longer wrapped with pcall. Instead we explicitly check if we're in a yieldable phase and set the lock timeout to 0 if not. This ensures that resty.lock will not attempt to sleep a the lock is already held.
2. We only re-schedule the function in a timer if resty.lock:lock() returned timeout and we're not in a yieldable phase

The only logic that was left up to the callers of run_locked was the handling of the re-schedule condition. This was done so that callers could log a more informative/context-aware message instead of just a generic "we re-scheduled some kind of function" log entry.

I think this is the correct way to address some of the observed problems, but review from somebody more knowledgeable with the project is very much needed. If it looks good I can port to the 1.x tree.

[CLAassistant]

All committers have signed the CLA.

[flrgh]

FYI I haven't really looked at the tests yet. I figure this could be a pretty difficult one to test, but if the approach looks sound I'll see if there's anything we can do to ensure test coverage.

[kikito]

I have mostly minor comments about the use of return values and the meaning of the first return value.