Deprecate redundant section configuration

[jamie-s-white]

This PR completely removes the section configuration parameter from this plugin, and instead runs all corresponding code through the criteria defined in the configuration. This has two main benefits:

1. It allows for an element to be in multiple indexes. At the moment, if we had, for example, a full site search collection with everything in it, and then individual more specialised indexes, before this update, then only the first index defined would be updated. This bug is related to the getCollectionBySection function, which can only ever return one index. Because I have now created a new getAllCollectionsElementIsIndexedIn function which now returns an array of all indexes the element lives in, all corresponding indexes are now updated.
2. It removes the confusion created by having both a section configuration and criteria, as exemplified by Question: Understanding section.entry-type? #60 . And because the plugin now uses the criteria configuration to power both full syncing and flushing of collections, as well as individual element saves and deletions, they now cannot get out of sync, like they can when having the section configuration present.

Because section is no longer used in any way, I have also added deprecation warnings if it stays in the configuration file. For example:

[michtio]

Hey @jamie-s-white sorry back in the office after a (long) summer break - thank you for these amazing PR's.
I'll make some time next week to review and merge these in.

Seeing you're using the typesense config. Would you be open to connect. As I'm in the works of rebuilding it from the ground up. Might be nice to have a discussion about it with someone actually using it intensively.