update Dapper and enable Dapper.AOT

[mgravell]

With .NET 8 shipped, Dapper.AOT can also ship, yay!

This change:

• updates the Dapper package (although I believe it won't actually be used any more, although I haven't checked the outputs)
• adds the Dapper.AOT package which contains generator support and a small runtime library akin to Dapper (no ref-emit)
• adds [DapperAot] usage to enable the generator (this step is opt-in)
  • ~~explicitly turns AOT in one broken scenario (will fix external lib ASAP)~~
• adds [CacheCommand] usage to allow DbCommand reuse
• enables interceptor support in the build SDK
• suppresses a warning about a particular usage (alternative options cited in comments, but left "as is" for comparison purposes)

[DamianEdwards]

Wondering if there's any value in keeping both Dapper and Dapper.AOT and testing them both? Or do you think we should just move to Dapper.AOT now?

[mgravell]

@DamianEdwards interesting question; I'm happy with either; I need to remember how to kick off test runs against branches - the data might help steer us there, although if it is useful I'm fine with keeping both - it just might complicate reporting

[DamianEdwards]

Perhaps for now we set the projects up to enable/disable Dapper.AOT via an MSBuild property that guards a compiler directive (#ifdef) even if just continue to report on one variant for now, we can do ad-hoc runs against either to compare? TBC I'm only talking about the benchmarks that aren't currently actually publishing native AOT. Our native AOT benchmarks should get new Dapper.AOT variants that we track.