This will be used to simplify the code in lib/net/imap/config.rb.
In this first step, only a couple pieces are extracted:
* `AttrVersionDefaults` stores the `Config.version_defaults` hash.
  The hash's `#default_proc` is defined there, too.
* `AttrVersionDefaults.compile` only freezes that hash.

This refactoring decouples the assignment of versioned default values
and the creation of `version_defaults` config objects.  At first,
`version_defaults` stores hashes for each version's updated defaults.
At the end, the hashes are transformed into config objects by
`Config::AttrVersionDefaults.compile!`.

This also causes Config[0.7r] through Config[1.0r] to be aliases (rather
than clones) of each other.

This avoids usage of the private `Config#defaults_hash` method, relying
instead on the public `#load_defaults` API.

At the cost of one big conflict now, this should significantly reduce
future merge conflicts in the config file.  It's also easier to match
documentation with default values when they're right next to each other.

This also assigns all of the original (`Config[0]`) defaults explicitly,
and not only where they differ from Config.default.

Similar to the versioned defaults, this could be a source of conflicts
when merging, rebasing, or cherry-picking feature and backport branches.
Now that all of the attributes specify their defaults, the current
version's default config can be compiled from that.

The sanity-check at the end of `config.rb` has been removed.  It was
there to protect against bad merges.  Now that `Config.default` is also
compiled from the version defaults added to each attr_accessor, the
tests in `test/net/imap/test_config.rb` are good enough.

♻️ Refactor Config.versioned_defaults to reduce merge conflicts (backport to 0.5)

According to the rdoc, using a range with `#delete?` should return a
sequence set (or nil), but the check came after importing the input, and
was based on whether the imported run contained multiple values.  So
deleting a single number range (e.g: `1..1` or `"1:1"`) would return a
number not a set.

This backports #580 to `v0.5-stable`.

When `SequenceSet#max(n)` is called with `n > cardinality`, it _should_
return a duplicate of the whole set.  But, `#max(n)` is implemented
using `#slice(-n..)`, and (copying the behavior of `Array`), when a
slicing starts from an out-of-range index, it returns `nil`.

It was using `-[count, size].min` to keep the index from going
out-of-range.  Prior to 0.6.0, `#size` is the same as `#count`, so it
gives incorrect results when the set contains an endless range.
`SequenceSet#cardinality` has not been backported to 0.5, so this makes
that calculation inline.

This change should also give a small performance boost, because it
bypasses the complexity of `#slice(range)` and just calls `#dup` (or
returns `self` when the set is frozen).

Now that `:frozen_dup` is the default behavior for `#responses` when
it's called without any arguments, a critical bug has become apparent:
it was not freezing the internal responses arrays directly, rather than
copies of them.  Freezing these arrays will, of course, lead to further
issues.

Ideally, code should be updated to use one of the other forms of
`#responses`, since this form is less efficient and also (intentionally)
incompatibile with old code that expects it to return mutable arrays.
But this is still a major bug.

Fixes #581, reported by @yurikoval.

`digest` 3.2.1 was released since the last `net-imap` release.  And
apparently `bundle exec rake release` activates `digest` _before_
loading the Gemfile.  But, since `digest` is a default gem anyway, not
including it in the Gemfile should be okay, I think.

See the errors here:
* 1st attempt: https://github.com/ruby/net-imap/actions/runs/20212203897/job/58019727242
* Merged #575
* 2nd attempt: https://github.com/ruby/net-imap/actions/runs/20219369554/job/58038064382