refactor: Synthesizerの実装をInner<_, A: Async>の形にする

[qryxip]

内容

#831 で残した次のTODOのうち、Synthesizerについてだけ解決します。

// TODO: `VoiceModelFile`のように、次のような設計にする。
//
// ```
// pub(crate) mod blocking {
//     pub struct Synthesizer(Inner<SingleTasked>);
//     // …
// }
// pub(crate) mod nonblocking {
//     pub struct Synthesizer(Inner<BlockingThreadPool>);
//     // …
// }
// ```

#687 のようなことを行うのを円滑にする目的です。今後ソングとかストリーミングとかでSynthesizerに手を入れることが予定されているので、その前に早めにやった方がよいと思った次第です。

なんかパフォーマンス的にはもしかしたら破壊的になってるかもですが、もしそうでもパフォーマンスだけならということでcommit typeはrefactor:としてしまいました。

関連 Issue

Refs: #831, #687

その他

そこそこ大きく手を入れているので、今度こそスナップショットテストを作った方がよいかも？

[Hiroshiba]

たしかにスナップショット導入できると嬉しいかもではありますね！！

エンジンリポジトリの方では、作った音声を有効数字何桁か絶対値何桁かでroundしたバイナリをハッシュ化してスナップショットにしてます。
たぶんosを限定するか、osごとにスナップショット取れば完全一致する気がします。

けどまあ、このprくらいなら気合いで目でチェックも不可能ではなさそうなのと、あとは @Yosshi999 さんが作ってくださったpython用チェックコードを手元で動かしてみるとかでも良さそう！！

[qryxip]

けどまあ、このprくらいなら気合いで目でチェックも不可能ではなさそうなのと、あとは @Yosshi999 さんが作ってくださったpython用チェックコードを手元で動かしてみるとかでも良さそう！！

mainと比較しましたが、Yosshi999さんのスクリプトを使うまでもなくWAVが完全一致しました。
（というのも、処理自体は一切変わっていないはずなので）

❯ diff {a,b}.wav; echo $?
0

[Hiroshiba]

ほぼLGTMです！

ちょっとSynthesizerがだいぶリッチになってきたというか、内部用の処理を持ち始めてるかもと感じました。
Synthesizer内でndarrayが現れないようにするときれいに分離できるかも。
（まあcompatible engine側との都合もあるかもですが）

[qryxip]

割とありかなと思います。synthesizer.rsとは別ファイルの、engine/synthesis.rsとかでimpl Status<_>の延長（あるいはtrait StatusExt)を書くという形がよいかなと。実質的な「層」にはなるかもですが、Synthesizerから直接Statusが透けて見える分認知負荷は抑えられるはず？

[Hiroshiba]

LGTM！！

[qryxip]

c941504 (#865)を入れてしまいましたが、マージしちゃおうと思います！