Use DependencyResolver instead of IvySbt#Module directly

[mdedetrich]

So this PR is the result of me going down a giant rabbit hole. The original improvement I was trying to do is replacing the usage of IvySbt#Module because I was experiencing sbt/sbt#3618 and the workaround at sbt/sbt#3618 (comment) for some reason didn't work (I guess sys.props was not being passed to sbt plugins due to classloader isolation???).

So after wasting a stupid amount of time figuring out if I could somehow pass the packaging.type manually into Ivy, I just figured why not just entirely replace IvySbt#Module with sbt's update task, that way we can also benefit from Coursier's faster dependency resolution (little tidbit, but sbt-license-report can end up taking ages in some cases due to Ivy)? Then this is where the rabbit hole began, I ended up hitting coursier/coursier#1790 (tl;dr version, Coursier doesn't properly grab the license information when using IvySbt#Module as a module). IvySbt#Module also needs to be used because certain dependencies don't hold the license info in pom.xml (see https://discord.com/channels/632150470000902164/922600050989875282/1151492070373085306).

So rather than using update I instead opted for IvyDependencyResolver. While it doesn't go the full way of just using update to get all of the dependencies and their respective licenses, the data structures returned by both DependencyResolution.update and sbt's update task are the same (i.e. UpdateReport) so once that coursier issue is solved a future PR to use update will be trivial.

The PR also drops support for SBT 0.13.x because its ancient and DependencyResolution doesn't exist there.

[eed3si9n]

Thanks @mdedetrich!