this commit introduces a breaking change for apps using the class method `alchemy_resource_filters` in their models used in custom modules.

The change introduces a new data structure for defining filters. It allows to set up multiple filters in two different ways:

* where the filter name is assumed to be a scope on the model and the values are passed as the argument
* where the filter values are assumed to be scopes on the model (basically as it was until now)

Example:

```
class Mymodel < ApplicationRecord
  scope :by_language, ->(lang) { where(language: lang) }
  scope :published, -> { where(published: true) }
  scope :drafts, -> { not.published }

  def self.alchemy_resource_filters
    [
      {
        name: :by_language,
        values: distinct.pluck(:language)
      },
      {
        name: :status,
        values: %w[published drafts]
      }
    ]
  end
end
```

Both, the name and the values can be translated. Since the filter values are passed into the `options_for_select` helper, they can be provided in two ways: array of strings/symbols, or as an array of arrays. In the first case Alchemy will lookup a translation in `alchemy.filters.<name_of_filter>.values` whereas in the second case the provided values will just be passed to into `options_for_select` directly.

There are two security measures in place against filter param tempering:

1. Arriving filter values must match the values defined in the model. If the value doesn't exist, the parameter gets rejected and the value won't be send to the model.

2. Rails' strong parameters is used for the case where someone tempered with the parameter names. If a name and doesn't match one of the defined filter names in the model it won't get the permission to pass.

…ination

This commit is supposed to be reverted after Alchemy v6.0 is released.