Fixed #29317 -- Clarified filter argument in PostgreSQL aggregate functions.

[shalgrim]

First time contributor at DjangoCon US 2018 making a documentation change per Issue #29317.

The discussion in that ticket thread indicated the best fix to the confusion in the existing documentation was to add this note with this link.

[timgraham]

I'm not sure -- it feels odd to give a special call out like that. I'm thinking it may make more sense not to document filter=None in every subclass and instead leave it at **extra, similar to model fields where we don't document all the common options for every field. \cc @orf

[timgraham]

@charettes, what do you think of this approach? (As opposed to documenting distinct for every function in #9174.)

[charettes]

@timgraham I think I'd make sense. Something I noticed while working on #9174 is that we already document it for all aggregates in the Aggregate documentation.

django/docs/ref/models/expressions.txt

Lines 421 to 423 in b4714a3

	The ``filter`` argument takes a :class:`Q object <django.db.models.Q>` that's
	used to filter the rows that are aggregated. See :ref:`conditional-aggregation`
	and :ref:`filtering-on-annotations` for example usage.

Maybe we should just like there from the contrib.postgres.aggregate documentation? filter happens to be implemented differently on PostgreSQL but it's support on all backends so I'm not sure why it should be special cased in contrib.postgres docs.

[timgraham]

Yea, okay. I guess removing it from the signature could be confusing.