Use `Results` class for visualisations

[`Results`](https://github.com/UUDigitalHumanitieslab/I-analyzer/blob/develop/frontend/src/app/models/results.ts) is an abstract class in the frontend that is designed to handle various types of results based on a query. A child class will have some parameters of its own (or none), and fetch results when the query or the parameters change.

This class is currently used to fetch the [(paged) document results for a query](https://github.com/UUDigitalHumanitieslab/I-analyzer/blob/develop/frontend/src/app/models/page-results.ts), but it was written so that it could also be the basis for visualisations. The advantage of this is that `Results` includes some logic that won't need to be repeated for every visualisation. It also results in a more consistent flow in the application.

However, visualisations are complex modules that tend to include some complex logic of their own, so this refactor isn't trivial

To fully use the `Results` class, I would propose (in this order):

- [x] a `FrequentWordsResults` class that generates results for the wordcloud.
- [ ] an `NgramResults` class that generates results for the ngram visualisation.
- [ ] a `DocumentFreqResult` class that generates a histogram of document frequency in relation to a keyword or date field. Create subclasses for those two scenarios. Used for the document frequency graph.
- [ ] a `TermFreqResult` class that generates the frequency of the search term in relation to a keyword or date field. Used for the term frequency graph.

Some considerations:
- The wordcloud is the easiest case, because it doesn't feature any additional parameters or extra logic.
- The ngram visualisation has a lot of parameters, but that should map well to how `Result` already works.
- An additional complexity is the use of caching, but I don't think that should raise any particular difficulty. Write `NgramResult.fetch()` so it uses the cached data in the same way that `NGramComponent.loadGraph()` currently does.
- Another issue is that you need to request that the visualisation task is cancelled when the model stops observing it - usually because the parameters change.
- The document frequency graphs have a straightforward fetching function, but for _date_ histograms, they have the complexity that we need to fetch higher-resolution data when zooming in (e.g. per month rather than per year), and project the data for the zoom window onto the current data in the graph. Not sure how to go about this. Create an additional `DocumentFreqResult` for the smaller interval?
- At this point, writing the `TermFreqResult` should be relatively straightforward. However, the barchart module is a beast - refactoring it to use the `DocumentFreqResult` or `TremFreqResult` is welcome but not trivial.

Bonus points:
- [ ] a `AggregationResult` class that fetches the document counts displayed in the multiple choice filter. Could also be based on `DocumentFreqResult`.
- [ ] a `CountResult` class that just fetches the total number of documents, that can be used in the download component (used to determine the download type).