[18.0][ADD] payroll_rule_tag: tag salary rules and use tag totals in computations

[nimarosa]

Adds payroll_rule_tag: Salary Rules can carry any number of Tags, and each tag's
total is exposed to salary rule computations as tags.<CODE>.

Tags are a more flexible alternative to Salary Rule Categories: a rule belongs to a
single Category, but can carry any number of Tags, and tags may freely overlap. The
typical use is grouping rules into calculation bases — "Taxable", "Social Security",
"Benefits" — and computing each base as the total of the rules carrying that tag,
instead of repeating a list of rule codes in every formula:

result = tags.TAXABLE

Extraction note

Extracted from #174 (author @dreispt) to allow individual review/merge. The original
[ADD] payroll_rule_tag commit is cherry-picked unchanged with its authorship
preserved; #174 bundles several unrelated modules, which is why this one never got
reviewed on its own.

Completed on top of the original module

Configuration and multi-company

• optional Code field, so the identifier salary rules use no longer has to be the
  tag name
• company_id plus a multi-company record rule, list/kanban/search views, and ACLs
  split between Payroll Officer (read) and Payroll Manager (full)

Fixes

• salary_rules_ids declared an explicit relation table while hr.salary.rule.tag_ids
  left it implicit, so the two fields were backed by different tables instead of
  being the two sides of one relation: tagging a rule never showed up on the tag's
  Salary Rules page and # Rules stayed at 0. The fix drops the explicit parameters
  rather than adding them on both sides — hr.payslip.line prototype-inherits
  hr.salary.rule, so an explicit table on tag_ids is copied to it and the registry
  refuses to build with two models sharing one many2many schema.
• the tag code fell back to the tag name, which is translatable, so a payslip
  computed in a language having a translation for the tag resolved to a different code
  than the one written in the rule. BrowsableObject returns 0.0 for an unknown key,
  so this silently produced a wrong amount instead of an error. The fallback now reads
  the source value.
• two tags could resolve to the same code ("Net Pay" / "Net-Pay", or a code equal to
  another tag's normalized name) and silently accumulate into a single total. Added a
  constraint rejecting duplicate effective codes per company; the existing SQL
  constraints only caught exact matches.
• the kanban view used the deprecated t-name="kanban-box", which warns on every view
  load in 18.0; migrated to the card API.

Tests — 24 tests covering tag defaults and code resolution (explicit code,
normalized name, language independence), the constraints, both sides of the rule/tag
relation, ACLs and the multi-company rule, and the payslip behaviour: totals per tag,
unknown tags evaluating to zero, untagged rules staying out, totals summing line totals
rather than unit amounts, archived tags dropping out, and recomputing a payslip not
doubling the totals.

Packaging — version reset to 18.0.1.0.0 (the module was never released), readme
fragments completed (DESCRIPTION / CONFIGURE / USAGE / ROADMAP / CONTRIBUTORS), and
es / es_AR translations added.

@dreispt this is your module — could you take a look?

[nimarosa]

@dreispt @norlinhenrik @CristianoMafraJunior @pedrobaeza
Please any of you can review so i can merge it soon? I'm using it in production and consuming the PR but would be nice to ship it with payroll directly.

[pedrobaeza]

You should squash your commits into less of them, as they are not adding value for the final result.

[nimarosa]

@pedrobaeza Done ;)

[pedrobaeza]

Now you have squashed into one, removing @dreispt attribution. He should check as well the final state.

[pedrobaeza]

I mean there should be at least 2 commits: Daniel's one, and yours.

[nimarosa]

@pedrobaeza I left @dreispt attribution in the commit. But okay, I make two commits if you thinl it's better.