refactor: `frame/` のリファクタリングと、使い方解説ドキュメント

[laysakura]

Issueへのリンク

Fixes: #610 Fixes: #611

（e2e テストを走らせたく、ブランチ名を変えるために #638 を閉じて立て直しました）

やったこと

frame/ 以下のフレームワークはとても良いもの（特に ecall_entry_point() を中心とした設計）だと思うが、実際に使ってみて慣れるまでに時間がかかったのと、名称や構造に一部違和感があったので、リファクタリングをする。 またフレームワークの使い方ドキュメントがあると新feature実装や改修の際に役立つと感じたので追加する。

• [x] 使い方解説ドキュメント追加
• [x] ドキュメントの TO-BE に合わせてリファクタリング
• [x] その他のリファクタリング
  • trait {Basic,StateRuntime}EnclaveUseCase の関連関数にデフォルト実装がついていたのを外した。デフォルト実装に気づかず全部 impl したつもりになって、ランタイムでデバッグする必要に迫られるのを避けるため。
  • anonify-enclave のほうでHostInputやHostOutputに signer, gas を持たせていたが、本来どちらの持ち物でもない（use case計算の入出力どちらでもない）ので外に出した

やらないこと

誰か今後書いてくれたら嬉しいな

動作検証

CI pass (含む e2e） テストのカバレッジを知らないので、これでどの程度自信を持ってよいのか...

特に、 cmd: u32 の付け間違えなどに一抹の不安... → この箇所はセルフレビューでだいぶ自信持てた

参考

• frame を使っている箇所が多いので、どうしても差分が大きくなっています。意味単位でcommitしているので、commitごとに見たほうがやや見やすいかもしれません。
• 元の author である osuketh さん、別リポジトリで frame をメインで使っている cipepser さんのお二人にレビューもらいたいです。
  • おすすめの読み方: 最初にcommitごとにメッセージと差分をチラ見していき、どんな変更を加えていったのか意図を頭に入れる。その後 Files changed で全差分を確認。
  • レビュアーが2人なこともあり、私の方でペアレビュー会を開催するのが一番効率いいかもしれません。

[laysakura]

レビューありがとうございましたﾏｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｼﾞします！