feat(charge_filters): add code to identify filters

[brunomiguelpinto]

Context

A charge filter has no stable identity. It is known by its values, and those move: removing a value
from a billable metric trims it out of every filter using it, so two filters that were distinct can
collapse onto the same values and stop being distinguishable.

{region: [us], tier: [gold]}    @0.02     ->  {region: [us]}  @0.02
{region: [us], tier: [silver]}  @0.015    ->  {region: [us]}  @0.015

Propagating a plan's charge to its overrides pairs filters by those values, so once that happens it
can reprice the wrong one.

Description

Charge filters get a code, derived from the values a filter is created with and frozen from then
on, so a filter keeps its identity even when its values move. An override inherits the code of the
filter it was copied from rather than deriving its own — that inheritance is what records the link
between the two.

A filter that exists only on the override, because the customer negotiated a segment the plan
does not price, derives its own code: there is nothing to inherit from, and it is not orphaned
either. If the plan later gains that predicate it derives the same code, so the two line up by
construction rather than by luck.

Backfilling existing rows

One walk, over the charges belonging to a plan, a job per charge. Each job derives the codes for its
own filters and then hands its overrides on to a second job

The unit of work is a charge on the way in and a parent on the way out, because every override of a
charge answers to the same set of codes.

What stays NULL, on purpose

• a charge holding two filters on one predicate — whichever kept the code would be the one that
  bills from then on, and that is not a migration's call. Only the colliding filters are skipped;
  their siblings are still filled.
• an override holding a filter its plan no longer has — nothing left to link it to, either
  because the plan dropped it or because the parent charge was deleted and dependent: :nullify cut
  the link. Damage already done; no backfill undoes it.
• a filter whose code a sibling already holds, frozen when that sibling's own values were these —
  writing it again would break the unique index on (charge_id, code).
• organizations with nothing active or pending, and deleted plans — not billing, not worth the work.

rake filters:report_codes reports what is left and why. Cleaning up the first kind and running the
upgrade task again converges, since a cleaned charge goes back to having filters without a code and
the walk selects it again.

[annvelents]

Agree on @tiagolupepic's comments, but LGTM! 🚀