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

Inizia esaminando la Filter API esposta e i relativi test, che l’issue identifica come interessati dalle modifiche proposte alla firma. Esamina quindi come vengono gestite le macro clean e smudge di .gitattributes; per considerare il lavoro completato sono necessari un design dell’API concordato, i dipendenti aggiornati e test superati.

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