⬆️ Bump dependencies versions

[Glutexo]

Ensure all dependencies use their current latest stable version compatible with Elixir 1.10 if that version doesn’t break the code. This change may make sense only after introducing floki by #87. (Originally suggested in https://github.com/Glutexo/onigumo/pull/87#discussion_r1084020328.)

[Glutexo]

Additional notes:

We list httpoison as ~> 1.8, not ~> 1.8.0. Although the Hex repository suggests this, I’d pin the minor version and only automatically upgrade the patch versions, which should not introduce breaking changes. Also, there is already a 2.0.0 version of the library, which is worth considering. (Update: it is safe to upgrade.)

mox already has a 1.0.2 version; our Mix lock file lists 1.0.1. mix.exs uses ~> 1.0, and as with httpoison, I suggest pinning to the patch version.

Elixir, specified as ~> 1.10, allows using a newer minor version. We downgraded to 1.10 to ensure compatibility with Debian. If we pinned dependencies to their minor versions, only allowing patch upgrades, shouldn’t the same apply to the language?

Also, does the reason for using such an old version still pertain, @nappex? Or are you ok with using a more modern one?

With a quick search, I couldn’t find any reliable source supporting my inclination towards allowing patch-level upgrades only. My justification is that patch versions introduce fixes (also security ones) but don’t change behavior. Feel free to object: I’d love to hear counter-arguments.

[Glutexo]

I read the changelog for httpoison 2.0.0: it only changes how SSL options are processed. We don’t configure SSL by ourselves, so we can safely upgrade.

[nappex]

Currently, we have a problem with Floki added in #87 , the latest version is 0.34.0. With our specification elixir dont want to update to 0.34.0 and keep 0.32.1

[Glutexo]

Both @Glutexo and @nappex currently use Elixir 1.16.x. We don’t need to stick with 1.10, which we only retained because of Debian, which @nappex used to develop on.