feat: Add support for unicode parameter in emoji type of rich text bl…

…ocks (#1319)

This PR adds support for the `unicode` parameter to the
`RichTextSectionEmojiElement` struct for rich text blocks. While this
parameter is not officially documented in Slack's API, it is present in
the JSON payload of actual Slack messages and represents the Unicode
code point of the emoji.
https://api.slack.com/reference/block-kit/blocks#emoji-element-type

For example, a rich text block with an emoji can include the unicode
field like this:

```json
"blocks": [
    {
      "type": "rich_text",
      "block_id": "xxxxx",
      "elements": [
        {
          "type": "rich_text_section",
          "elements": [
            {
              "type": "emoji",
              "name": "+1",
              "unicode": "1f44d"
            }
          ]
        }
      ]
    }
  ]
```

The unicode parameter behaves similarly to the skin-tone parameter,
which is also undocumented but has already been included in the
structure. This PR aligns the handling of unicode in the same way to
ensure emojis are fully supported in Slack message payloads.

Please review, and feel free to provide feedback if any adjustments are
needed. Thank you!



##### Pull Request Guidelines

These are recommendations for pull requests.
They are strictly guidelines to help manage expectations.

##### PR preparation
Run `make pr-prep` from the root of the repository to run formatting,
linting and tests.

##### Should this be an issue instead
- [ ] is it a convenience method? (no new functionality, streamlines
some use case)
- [ ] exposes a previously private type, const, method, etc.
- [ ] is it application specific (caching, retry logic, rate limiting,
etc)
- [ ] is it performance related.

##### API changes

Since API changes have to be maintained they undergo a more detailed
review and are more likely to require changes.

- no tests, if you're adding to the API include at least a single test
of the happy case.
- If you can accomplish your goal without changing the API, then do so.
- dependency changes. updates are okay. adding/removing need
justification.

###### Examples of API changes that do not meet guidelines:
- in library cache for users. caches are use case specific.
- Convenience methods for Sending Messages, update, post, ephemeral,
etc. consider opening an issue instead.

block_rich_text.go

@@ -341,6 +341,7 @@ type RichTextSectionEmojiElement struct {
 	Type     RichTextSectionElementType `json:"type"`
 	Name     string                     `json:"name"`
 	SkinTone int                        `json:"skin_tone"`
+	Unicode  string                     `json:"unicode,omitempty"`
 	Style    *RichTextSectionTextStyle  `json:"style,omitempty"`
 }
 

block_rich_text_test.go

@@ -187,6 +187,16 @@ func TestRichTextSection_UnmarshalJSON(t *testing.T) {
 			},
 			nil,
 		},
+		{
+			[]byte(`{"type": "rich_text_section","elements":[{"type": "emoji","name": "+1","unicode": "1f44d-1f3fb","skin_tone": 2}]}`),
+			RichTextSection{
+				Type: RTESection,
+				Elements: []RichTextSectionElement{
+					&RichTextSectionEmojiElement{Type: RTSEEmoji, Name: "+1", Unicode: "1f44d-1f3fb", SkinTone: 2},
+				},
+			},
+			nil,
+		},
 	}
 	for _, tc := range cases {
 		var actual RichTextSection