Add deprecation notice to README.md

[aburdenthehand]

We've had a few folks on the mailing list have troubles with this, since it has not been maintained in a while but is automatically updated, which gives the appearance of the repo still being supported.

We had previously put a call out for maintainers for this repo but did not receive enough volunteers.

What this PR does / why we need it:

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #

Special notes for your reviewer:

Checklist

This checklist is not enforcing, but it's a reminder of items that could be relevant to every PR.
Approvers are expected to review this list.

• Design: A design document was considered and is present (link) or not required
• PR: The PR description is expressive enough and will help future contributors
• Code: Write code that humans can understand and Keep it simple
• Refactor: You have left the code cleaner than you found it (Boy Scout Rule)
• Upgrade: Impact of this change on upgrade flows was considered and addressed if required
• Testing: New code requires new unit tests. New features and bug fixes require at least on e2e test
• Documentation: A user-guide update was considered and is present (link) or not required. You want a user-guide update if it's a user facing feature / API change.
• Community: Announcement to kubevirt-dev was considered

Release note:

[brianmcarey]

/lgtm

[donjmilligan]

I would like to find some people on our team to maintain this since we have a huge cloud project that needs it. How much time do you think it needs on a release by release basis?

[fabiand]

IMHO you can probably maintain this project with a low amount of maintenance work by

1. automating most of the stuff
2. aligning releases to kubevirt releases