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

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

首先检查公开的 Filter API 及其相关测试，issue 指出它们会受到拟议签名更改的影响。然后检查如何处理 .gitattributes 的 clean 和 smudge 宏；完成这项工作需要达成一致的 API 设计、更新依赖方并通过测试。