bug: the hot reload procedure is not robust

### Current Behavior

the hot reload is vulnerable to two issues

1. **Incomplete state if `init()`/`destroy()` throw**: `apisix/plugin.lua` calls `destroy()` then `init()` on each plugin synchronously during reload. If any of these throws,
some plugins are destroyed but not restarted, leaving `plugin.plugins` in a permanently
inconsistent mixed old/new state.

2. **Requests served with incomplete plugin set during reload**: When `plugin.lua` `require()`s a
new plugin module, if that module's top-level code yields (cosocket, `ngx.sleep`), the nginx
scheduler resumes other coroutines. An incoming request can then run through `plugin.plugins`
while it only contains the subset of plugins reloaded so far — a partial, inconsistent plugin
set processes live traffic.

### Expected Behavior

atomic switch to new plugins and then tear down old plugins
this require careful design

### Error Logs

none

### Steps to Reproduce

none

### Environment

does not matter

Start by reading the reload path in apisix/plugin.lua, focusing on how plugin modules are required and how destroy() and init() are sequenced. Trace the coroutine and request paths involved, then define and test a reload design where requests see either the old or new complete plugin set and old plugins are torn down only after the switch.

Written by the indexing model from the issue text.