Document our use of epics and issues

Document our use of epics and issues:

• Sprint-ready issues should specify small, well-contained tasks.
• Issues which unpack into sets of smaller issues within the same project should be treated as "mini epics" and have sub-issues attached as related issues.
• Issues which unpack into sets of issues across projects should be created as epics. Epics should be created as high up the hierarchy as makes sense since issues and sub-epics which are not within an epic's group cannot be added.
• Long-term plan epics for each of our products should be created at uis/devops level.
• Epics representing live workstreams should be added to the live workstream epic.

Epics are used to track multi-sprint work items which span multiple projects. Multi-sprint issues which within a single project should use tracking issues with related sub-issues for the simple reason that epics cannot be created on a single project.