Definition of a good-first-issue for the Dapr org

To enable new contributors to Dapr to pick up new issues easily, it is important to create GitHub issues targeted to these contributors. These issues are known as good-first-issues, and they have a dedicated label in the Dapr repositories to identify them as such.

Unfortunately, most of [these issues](https://github.com/search?q=org%3Adapr+type%3Aissue+label%3A%22good+first+issue%22++&type=issues&state=open) are not clear and thus hard to pick up by new contributors. I suggest we strive to use a good-first-issue format (or template) which makes it easier for people to understand the issue and contribute to Dapr.

---
A good first issue in the Dapr org should contain the following sections:

### Current behavior

_Describe what the current behavior is._

### Steps to reproduce

_Describe how to get to the current behavior._

### Expected behavior

_Describe what the expected behavior is._
_Also include what it should NOT do if you think that is important._

### Acceptance criteria

_A list of criteria that must be completed before this issue is marked as completed_
_Does this require new unit tests?_
_Do existing unit tests need to be updated?_
_Are updates to the docs required?_

### Required skills & tools

_Describe what technical skills and tools are required to work on this issue_
_Link to a contributing guide_

---
Can the maintainers agree on the above sections? The community managers can help add some structure and context, but the majority of the work is still to be done by the maintainers/existing contributors.