Closes #1296.

Per discussion in #1296, DuplicateFareRuleZoneIdFieldsValidator says the combination of route_id, origin_id, destination_id, and contains_id must be unique in fare_rules.txt, when the spec says fare_id should be included (aka the primary key is all fields). This PR drops the custom validator in favor of proper @PrimaryKey annotations for fare_rules.txt.

Per the acceptance tests, there are a number of feeds (~60) that trigger the existingduplicate_fare_rule_zone_id_fields notice. Spot checking a few feeds, many of them are indeed specifying the same combination of fare rules with different fare ids. The corresponding fare attributes often have a different price, probably indicating that the producer is attempting to model some other aspect of their fare system (different fare products? different rider categories?) despite the fact that this is not really supported in Fares v1. While it's maybe not obvious how feed consumers should productively use this data, other than showing the cheapest fare, the spec technically allows it, so the validator should as well.

The acceptance test shows that a number of feeds (~10) newly trigger a duplicate_key notice. These are all feeds that really due have a duplicate combination of all fields in fare_rules.txt. However, each of these feeds were already triggering a duplicate_fare_rule_zone_id_fields notice, so there are no newly-invalidated feeds from this change.

• Run the unit tests with gradle test to make sure you didn't break anything
• Format the title like "feat: [new feature short description]". Title must follow the Conventional Commit Specification(https://www.conventionalcommits.org/en/v1.0.0/).
• Linked all relevant issues