The Filter API contains singleton Entry-points which are agnostic to `FilterMode`, does having `Clean` and `Smudge` entry-points make sense?

まず、issue で提案されたシグネチャ変更の影響を受けるものとして特定されている、公開された Filter API と関連するテストを確認します。次に、.gitattributes の clean マクロと smudge マクロがどのように処理されるかを調べます。完了には、合意された API 設計、更新された依存側、およびテストの成功が必要です。

Today the Filter object (the API we expose to lib consumers) contains the following entry-points:

• virtual void Initialize()
• virtual void Complete(string path, string root, Stream output)
• virtual void Create(string path, string root, FilterMode)
• virtual void Clean(string path, string root, Stream input, Stream output)
• virtual void Smudge(string path, string root, Stream input, Stream output)

This is very uneven and, to my OCD, a fairly inconsistent API. I'm responsible and I'd like to change it, however some have already taken a dependency. In the spirit of #1103 I suggest changing the API to the following.

• virtual void Initialize()
• virtual void Complete(string root, string path, Stream output, FilterMode mode)
• virtual void Create(string root, string path, FilterMode mode)
• virtual void Apply(string root, string path, Stream input, Stream output, FilterMode mode)

I believe this is a simplified API which presents a consistent set of entry-points, and leaves the mode management up to the implementation of Filter. I'll happily make the changes and update the associated tests.

As a side note, I had a side-band discussion with @ethomson about how to handle the .gitattributes macros (example: [filter "lfs"] \n clean = git lfs clean %f \n smudge = git lfs smudge %f). While there are normal situations when you just know(tm) what to do on smudge and clean callbacks, ideally the filter would at least aware if the user has edited the values of the macro.

Assuming we can find a solution, whatever solution we'll find will likely end up impact this API. Perhaps then we should combine the two discussions here.

/CC @ammeep @shiftkey @nulltoken