Fix Gradle build deprecation warnings and improve type safety

[NaMinhyeok]

Changes

• Replace deprecated java.net.URL and HttpURLConnection with Ktor HttpClient in slackNotification task
• Fix deprecated intellijPlatform API calls:
  • create(ideaType, ideaVersion, useInstaller) → create(ideaType, ideaVersion) { this.useInstaller = useInstaller }
  • verifyPlugin → pluginVerification
• Add explicit Task type parameters to all tasks.register() calls to resolve Kotlin type inference warnings

Background

First of all, thank you for creating IdeaVim - I use it extensively and it's been incredibly helpful in my daily workflow.

When I forked the repository and attempted to build it, I noticed numerous deprecation warnings and type interface warnings in the build process. I took the initiative to address these issues to help improve the overall code quality and reduce build noise.

After reading the CONTRIBUTING.md guide, I realized there might be some confusion on my part regarding whether I should have created a discussion or filed an issue before starting this work. I decided to go ahead and submit this PR directly, but I apologize if I didn't follow the proper protocol. Please let me know if there's a preferred process I should have followed for this type of maintenance work.

I hope these changes are helpful. This is my first contribution, so any feedback would be appreciated!

[AlexPl292]

Hi there! Thank you for your contribution and the feedback about the guide. I'll review whether I can make it clearer that you can simply go and file a pull request.

[AlexPl292]

Do I get it right that this part caused the confusion?

🔸 Selected an issue to work on? Leave a comment in a YouTrack ticket or create a draft PR to indicate that you've started working on it so that you might get additional guidance and feedback from the maintainers.

[NaMinhyeok]

Thank you for the comment and clarification!

First, please note that I'm not a native English speaker, so I may have misunderstood the guidance.

Yes, that part exactly caused my confusion. I interpreted it as having two required steps before submitting any PR:

1. Create an issue first, or
2. Create a draft PR

Since I had already completed my changes, I wanted to submit them directly as an open PR. However, I thought I needed to either create a draft PR first to discuss the approach or create an issue to report these problems before submitting. This made me worry that opening a completed PR directly might violate the contribution guidelines, even though I knew these weren't major issues 😅

There's nothing wrong with your guidelines, but I wanted to share this experience in case it helps clarify the process for future contributors who might have similar confusion.

I appreciate your patience with my first contribution!