Added missing handler README files; moved deprecated handlers; added …

[jeffbl]

This PR is for text changes to README files, plus moving two handlers into the "deprecated" directory since they were already marked deprecated in their README files (so I assume they were no longer being built, but I did not verify). There were some missing README files for some of the debug handlers, so I added stub READMEs that should still be filled out.

@JRegimbal assigning to you for an overall look, to make sure I've labeled appropriately based on guidelines in work item, with a bit of judgment where it was fuzzy.

@jaydeepsingh25 ping in case you want to look at the preprocessor alpha/beta decisions, but not necessary.

Please ensure you've followed the checklist and provide all the required information before requesting a review.
If you do not have everything applicable to your PR, it will not be reviewed!
If you don't know what something is or if it applies to you, ask!

Don't delete below this line.

---

Required Information

• I referenced the issue addressed in this PR.
• I described the changes made and how these address the issue.
• I described how I tested these changes.

Coding/Commit Requirements

• I followed applicable coding standards where appropriate (e.g., PEP8)
• I have not committed any models or other large files.

New Component Checklist (mandatory for new microservices)

• I added an entry to docker-compose.yml and build.yml.
• I created A CI workflow under .github/workflows.
• I have created a README.md file that describes what the component does and what it depends on (other microservices, ML models, etc.).

OR

• I have not added a new component in this PR.

[jeffbl]

I have now disabled the hello-haptics-handler workflow action since that handler is now in the deprecated directory. I think this is the only one.

Note that there are errors for other PEP8 issues in some handlers/preprocessors that are precluding building. I don't believe these were caused by this PR, but were existing issues that are being hit due to attempted building via github actions.

[JRegimbal]

Generally seems good. The only thing that sticks out to me is that the SVG debug handlers are labelled as "ready to be tested by end users", which is odd if they're explicitly visual debugging resources.

[jeffbl]

Generally seems good. The only thing that sticks out to me is that the SVG debug handlers are labelled as "ready to be tested by end users", which is odd if they're explicitly visual debugging resources.

OK, going to merge. Yes, agree that they are visual debugging resources, but I'd say they are at a quality level where 1. they are deployed in production, and 2. could be used by end users reliably, including developers. If we labelled these alpha, it might deter use even for debugging...