Allow custom ImportResult subclass via :result_class option

[Fivell]

Summary

Adds a :result_class option to active_admin_import so users can plug in their own ImportResult subclass and collect adapter-specific data — most notably the inserted record ids that PR #191 was trying to expose.

This is the "extension point" alternative to PR #191's approach of hardcoding ids on the base class. The gem stays minimal and adapter-agnostic; users who need RETURNING-style data own that quirk in their app code.

Why

PR #191 proposed adding ids directly to ImportResult by forwarding result.ids from activerecord-import. The downside is that result.ids only behaves consistently on PostgreSQL (via RETURNING); MySQL and SQLite require extra options or simply don't populate it. Hardcoding it would mean the gem owns those cross-adapter quirks forever, and every future "I want X from the batch result" request becomes another PR against this gem.

Instead, this PR makes the result class itself pluggable. Users who want ids write a 5-line subclass and pass it via result_class:. They own the adapter caveats; the gem owns nothing extra.

Changes

• lib/active_admin_import/options.rb — adds :result_class to VALID_OPTIONS
• lib/active_admin_import/importer.rb — adds :result_class to the importer's OPTIONS whitelist; import_result now uses options[:result_class] if provided, falling back to the existing ImportResult class. The narrower import_options slice is unchanged, so :result_class doesn't leak into the activerecord-import call.
• lib/active_admin_import/dsl.rb — the user action block is now invoked via instance_exec(result, options, &block) (matching DEFAULT_RESULT_PROC's signature) so the captured data is actually reachable from user code. Existing zero-arity blocks are unaffected — Ruby procs ignore extra arguments.
• spec/import_spec.rb — adds a PG-only spec demonstrating the canonical PR Store result ids on ImportResult (postgres only) #191 use case: a custom subclass that captures result.ids and exposes them via the flash, asserted end-to-end through Capybara. The spec is wrapped in if ENV['DB'] == 'postgres' so it only runs on the Postgres CI job, where RETURNING makes the assertion meaningful.
• README.md — documents :result_class in the options table and adds a "Custom ImportResult" section with the full ids-capturing example, plus a note about adapter-specific behavior.

Test plan

• SQLite regression: bundle exec rspec spec/import_spec.rb → 49 examples, 0 failures (PG-only context correctly skipped)
• MySQL CI job green
• PostgreSQL CI job green (this is where the new spec actually runs)
• Full SQLite matrix green

Follow-up

Once this is merged, PR #191 can be closed with a comment pointing at the new :result_class option and the README example as the supported way to surface inserted ids.