feat(emoji)!: implement app emojis

[Snipy7374]

Summary

• Closes implement app emojis #1223

Checklist

• If code changes were made, then they have been tested
  • I have updated the documentation to reflect the changes
  • I have formatted the code properly by running pdm lint
  • I have type-checked the code by running pdm pyright
• This PR fixes an issue
• This PR adds something new (e.g. new method or parameters)
• This PR is a breaking change (e.g. methods or parameters removed/renamed)
• This PR is not a code change (e.g. documentation, README, ...)

[Snipy7374]

I marked this ready for review even though i still don't know if we should provide the ability to cache app emojis at startup, as you can see i did put a boolean argument but didn't implement any logic for it so far.

[Victorsitou]

In the documentation, referring the emojis as "application emojis" instead of "app emojis" would be more consistent

[Enegg]

Since .guild/.guild_id is changed to possibly return None, this is a breaking change. (Rename PR title to feat!(emoji): ...?)

Personally I'd rather see a separate class for app emojis.

[Enegg]

I'm strongly in favor of splitting the models into a GuildEmoji and AppEmoji. The current approach is pretty much saying "an Emoji can have both .guild_id and .application_id, one of, or neither!"

Anyhow, minor nitpicks below.

[Enegg]

Suggested change

	:attr:`Emoji.guild_id` can now be ``None`` is the emoji is owned by an application. You can use :meth:`Emoji.is_app_emoji` to check for that.
	:attr:`Emoji.guild_id` can now be ``None`` if the emoji is owned by an application. You can use :meth:`Emoji.is_app_emoji` to check for that.

[Enegg]

I think this comment is no longer saying anything useful, remove it perhaps?

[Enegg]

Suggested change

	if self.guild_id is None:
	return True
	return False
	return self.guild_id is None

[Snipy7374]

I'm strongly in favor of splitting the models into a GuildEmoji and AppEmoji. The current approach is pretty much saying "an Emoji can have both .guild_id and .application_id, one of, or neither!"

Anyhow, minor nitpicks below.

If we want to split them into different classes (I had this talk with @shiftinv in the past, but at the time they said it was fine to go with this approach) we would most likely split them into Emoji and AppEmoji to minimize breaking changes