Update coredata and audiofile every recognition

[shibukazu]

Related Issue

related to https://github.com/openly-jp/voscribe/issues/192

What

• 認識ごとにRecognizedSpeechおよびTranscriptionLinesをCoreDataに書き込む
• 認識ごとに結合した音声ファイルを作成し、保存
• 上記によって認識がキルされた場合でも途中結果が失われない

Memo

• 上記に付随し、認識結果を逐次(30sの塊ごとに)RecordDetailsで表示する機能に取り組んだが、以下の理由から難しい
• RecognitionPaneとRecordDetailsで状態の共有が難しい
  • Classは参照型であることから、RecognizedSpeechを変更しても変更は検知されない
  • ObservedObject化し、TranscriptionLinesを@Publishedとするアイデアも検討されるが、RecognitionPaneでObservedObjectを宣言することはできない。（ObservedObjectがOptional不許容のため）
  • Struct型として扱う方法もありえるが、サブスレッドではStructをうまく扱えない(refer structとclosure関連)

Test

• [x] 認識される前にアプリがキルされた場合にもクラッシュなどが起きない
• [x] 1分程度認識したのちにアプリがキルされた場合に途中までの認識結果が失われない
• [x] バックグラウンド状態が3分以上経過したあとにキルした場合に途中までの認識結果が失われない
• [x] 電源を落とした時に途中までの認識結果が失われない
• [x] 5分程度認識したのちにアプリがキルされた場合に途中までの認識結果が失われない

Archive

• [ ] finishRecording後にキルされた場合に備え、音声の総計時間を保存
• [ ] 総計時間よりも認識終了分の時間が短い場合に、追加の認識を後ほど行える

上記ToDoに関しては必要に応じて機能追加するとする

[shibukazu]

録音中の音声を常にメモリ上に保持するべきかどうかは以下の議論より、現状ではメモリ上に常に保持する方針を採用する。

んーなるほど、これはわからん笑 けど、なんとなく、どうせどっかのタイミングでメモリ使って全部ファイルのせるなら、ずっとそのままメモリにおいてたほうが効率がいいような気もする。多分一回開放したらまたmalloc的なので比較的でかい領域を確保しないといけなくなって、それが割とオーバーヘッドありそうな気もする。（もちろんディスクIOも大変だし）。まあそのせいでスワップ領域とかまで使い始めて逆効果の可能性もあるやろけど。でも正直iphone使っててインスタとかラインとか死ぬほどアプリ立ち上げててもそんな影響を感じないから、メモリに関してはそんな心配しなくていい説もわんちゃん？まあ結論よくわからん笑