Introduce ext.dota2 - Dota 2 Game Coordinator extension

[Aluerie]

🐸 Summary

This PR introduces ext.dota2 extension.

🖍️ TODO

🐍 Migrate ValvePython/dota2 implemented methods.

• 👨‍💼Player
  • request_profile
  • request_gc_profile (disabled by valve)
  • request_profile_card
  • request_player_stats
  • request_player_info (disabled by valve?)
  • request_conduct_scorecard (behavior score system was revamped though)
  • request_hero_standings
• ⚽Match
  • request_matchmaking_stats
  • request_match_details
  • request_matches
  • request_matches_minimal
  • request_top_source_tv_games
  • request_player_match_history
• 🥳Party
  Sorry, I'm not interested in implementing this atm.
• 🦞 Lobby
  Same^
• 🗣️Chat
  Same^
• 🤝Shared Objects
  • Maybe?
• 🛠️Utils
  • replay_url
  • replay_url_from_match
  • metadata_url
  • metadata_url_from_match

🔚 Checklist

• If code changes were made then they have been tested.
  • I have updated the documentation to reflect the changes. (a bit?)
• 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, ...)

[Gobot1234]

Thank you so much for this!

These don't need to be included, they are for steam non-sense.

Also if you wouldn't mind please could you clean up the enum names to remove underscores and normalise them to be PascalCase.

Finally could you add a very barebones test to the tests directory just to ensure that the client is importable

[Aluerie]

Thanks for the feedback!

Last time I had similar conversation (with Riot Games API wrapper developers) they actually had the opposite opinion - that it's better for both library devs and end-user to just follow "bad naming/practices/models" from the original devs instead of rethinking/over-cooking. The proto-models are here and kinda working - why not just give easy access to them, they aren't so bad, honestly.

Maybe affected by those, I just thought

• to compile all protos
• to list all known emsg-response pairs
• to have easy kwargs->proto interface and let the user do whatever with returned responses.
• only then implement helper methods which would modelize the responses.

But I definitely see your points/philosophy. Sorry that I was too linear. Let's modelize this stuff right away then. So... I've done a total overhaul of the PR (maybe I should resubmit it for cleaner commit history?). This is what I changed:

• In practice, this top source proto message has very little keyword combinations that work and make sense. Thus, I reimplemented this into 3 separate methods.
• I also implemented some models to wrap responses and its fields.
• deleted all unused enums and proto messages -> naming and steam nonsense problems are gone.
• intial test file.
• moved EMsg to enums.py in root of the extension (kinda like yours).
• renamed some files to feel more pythonic and less valve-gibbersih prefixes (kinda like yours).

[Gobot1234]

Overall looks very good, nearly there.

Last time I had similar conversation (with Riot Games API wrapper developers) they actually had the opposite opinion - that it's better for both library devs and end-user to just follow "bad naming/practices/models" from the original devs instead of rethinking/over-cooking

I wouldn't disagree if the names were consistent at the very least but with steam they aren't