FileSystem のエラーハンドリングを見直し

[lriki]

そもそも FileSystem が必要なのか？

Lumino の FileSystem の目的の半分は、アプリ開発でよく使用するユーティリティの提供。
エンコーディング指定のテキストファイル読み書きや、パターンマッチは std::filesystem には無いユーティリティである。

単純なファイルのコピーや削除であれば std::filesystem と機能的な差は無い。
ただし、短いパスの場合は Path 用の SSO が効くので、ln::String, ln::Path と併用する場合、全体的には std::filesystem より高速に動作する。

動機

Lumino の多くの API は発生しうるエラーをロジックエラー（ユーザーではなくプログラマが悪い）と考え、assertion または例外(選択可能) を投げて通知する。
基本方針は「プログラムを止める」である。

しかしファイル操作（に限らずIO関係はそうだが）はどうしてもプログラムの外部の要素が絡むので、ユーザーエラーは避けられない。
他のラフに使える API と同じような感覚で使うべきではないだろう。

現状、システムに近いネイティブアプリでの導入がある。
ここではスクリプト言語のような感覚で使えてしまう API はかえって危険だろう。