rearrange files into "Features", grouping controllers with their relevant services and other associated classes (it's VSA time!)

**Blocked by:**
* [disable auto-wiring; use attributes, instead](https://github.com/BenMakesGames/PoppySeedPetsAPI/issues/16)
* [split/refactor remaining controllers into feature folders](https://github.com/BenMakesGames/PoppySeedPetsAPI/issues/15)

**Context**

Symfony's default is a directory structure like this:

* src
* Controller
* Beehive controller with every beehive endpoint
* Zoologist controller with every zoologist endpoint
* All kinds of other controllers
* Service
* A beehive service, maybe
* A zoologist service
* All kinds of other services
* Repository
* Beehive repository with all the queries related to Beehives
* Pet repository with all the queries related to Pets
* All kinds of repositories

it sucks, because when you want to look at, for example, Beehive stuff, you're bouncing between:
* a Controllers dir with a ton of controllers, only one of which is the Beehive controller you care about
* a Services dir with a ton of services, and maybe only one is related to Beehive stuff? but maybe more? and maybe none??? who can say!
* a Repositories dir with a ton of repositories, and probably one related to Beehive stuff... but maybe also you need one query in the Pet repository, which is full of tons of other methods you don't care about...

^ this sucks.

here is A Better Way(tm) to structure a project (search the internets for "vertical slice architecture" or "VSA" to learn more):

* src
* Feature
* Beehive
* One beehive endpoint class
* Another beehive endpoint class
* Yet another beehive endpoint class
* A beehive service containing precisely the methods you need
* Maybe some other beehive service, because this one is about beehive helpers instead of the beehive itself, and it felt tidy to split that way
* Zoologist
* One zoologist endpoint class
* Another zoologist endpoint class
* A zoologist service
* All kinds of other "features"

**To Do:**

Move all the files around as described by "A Better Way(tm)", above.

* With few exceptions, the subdirs in `src/Controller/` correspond to a feature; that is, you can probably start by just taking a subdir out of `src/Controller/` and moving it into `src/Feature/`
* For a given feature, find any services (in `src/Service/`) that belong with that feature, and move them in
* If a service seems to serve multiple features, either split it up, or maybe it truly is a shared service, and it can stay in `src/Service/`
* Ditto for classes in `src/Functions/`
* Ditto for classes in `src/Model/`
* Ditto for classes in `src/Enum/`

Entities (in `src/Entity/`) will be left alone for now. splitting up the DB is beyond the scope of the issue.

It's totally fair to have a PR only address one or two such "Features" at a time. this issue will be closed when all controllers are moved into `src/Feature/`.

Start by reviewing the feature subdirectories under src/Controller/, then trace related classes in src/Service/, src/Functions/, src/Model/, and src/Enum/. Move one or two controller groups and their feature-specific classes into src/Feature/, leaving shared services and src/Entity/ in place. Done means all controllers are eventually under src/Feature/ and the application still works.

Written by the indexing model from the issue text.