Docs: Release notes for filter by filter fix (elastic#75749)

In elastic#74260 we disabled the "filter by filter" aggregations optimizations
when we couldn't be 100% sure that they were both faster and *safe* for
the cluster. Before that, mostly in the 7.13 line, we would aggressively
enable the optimization whenever we could and there were lots of cases
where the well meaning optimization was way way slower than the original
implementation. There were also cases where it'd fill up memory and
knock over the cluster! Disaster. With elastic#74260 we're safe. The
optimization still kicks in when its faster - like when the top level
query is empty - but otherwise it get's out of the way and lets all the
normal aggs run.

docs/reference/release-notes/7.14.asciidoc

@@ -20,3 +20,8 @@ Machine Learning::
 * Make atomic operations safer for aarch64 {ml-pull}1893[#1893]
 
 * Ensure bucket event_count is calculated for jobs with 1 second bucket spans {ml-pull}1909[#1909]
+
+Aggregations::
+
+* Only enable "filter by filter" optimization for `terms`, `date_histogram`,
+  `range`, and `fitlers` aggregation when we're sure it'll be faster {es-pull}74260[#74260]