feat: user apps

[shiftinv]

Summary

discord/discord-api-docs@1eaa1af :woo:

This is still wip. The current state already works fine, just lots of rough edges.
The API isn't... great. Particularly some of the terminology/naming used is just confusing, and some parts are just completely nontransparent wrt. defaults and fields taking priority over others. It is what it is. /shrug

Issues

A probably non-exhaustive list of things that are still missing, could be improved, or are still uncertain.

API issues/unclear behavior:

1. contexts does not default to [0, 1, 2] on the api side, despite the documentation's claims.
2. It's not clear how Application.install_params and .integration_types_config work together. Right now it seems that the latter takes precedence over the former, if set. The dev portal sends both, looks like the API isn't doing any data shuffling here.
3. Same thing goes for ApplicationCommand.dm_permission and .contexts. I'm not sure if we even want to deprecate dm_permission right now.
4. We might want to send a fixed default value for contexts instead of the current null, in case the API ever starts choosing for us.
5. The authorizing_integration_owners field is weird, and its structure varies heavily based on configuration/context of commands and interactions. It already has a lengthy docstring, but it might be easier to instead split it into two separate properties and add some of our own fallbacks.
6. message.interaction_metadata.name isn't documented - quote, "well it will still be there, but i dont want to officially document it". It's an optional field, so implementing it nonetheless is probably fine.

Bugs/Missing features:

7. This needs feat(interactions): deserialize channel from data #1012, a new implementation of feat!: provide guild objects in interactions when guild is uncached #647, and another branch I haven't PR'd yet, to be usable properly in guilds without the bot user. And then likely a ton of mocking for guild.me and several permissions-related methods. Still very uncertain about this part.
8. The GuildCommandInteraction annotation (which ends up setting dm_permission=False) silently conflicts with the contexts parameter. See 3.

QOL:

9. Bot-wide defaults for the two new command fields could be useful, but aren't trivial to implement. Might hold off on this for now.
10. There are no utility decorators yet (like @commands.default_member_permissions()).
11. Allowing a command e.g. in all contexts is very verbose due to contexts=[InteractionContextType.guild, ..., ...]. An .all() property on the two new enums could be useful, but also feels a bit weird. Might be resolved by 10. eventually.
12. As mentioned, the official naming is weird. "interaction context" vs "installation context"/"integration type" is easy to mix up, and "integration type" in itself just seems... wrong. Considering renaming all integration_types to installation_types (the one combination of these words that the api docs don't use!).
13. More naming stuff can be found at various TODOs in the code.

Documentation:

14. The docs page still needs updates.
15. changelog tbd

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, ...)