feat: Add @CurrencyAmount annotation for currency amount validation

[bdferris-v2]

This will be used for various fields in the Fares V2 spec to reduce duplicate validation logic. Specifically, I will use this functionality in PR #1228 but I'm splitting it out to simplify the review.
Please make sure these boxes are checked before submitting your pull request - thanks!

• 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

[isabelle-dr]

Is this ready for review @bdferris-v2 ? 😊

[bdferris-v2]

Yes.

[maximearmstrong]

Thanks for this contribution @bdferris-v2! I've added a few comments.

[maximearmstrong]

Is there a reason why this generator would receive the fileDescriptors through the generateValidatorFiles() method instead of the constructor? I'm fine with your approach, I'm just wondering if all generators should follow the same design for consistency and maintainability. Thoughts?

[bdferris-v2]

When I look at all this code in GtfsAnnotationProcessor, there seems to be a recurring pattern of:

for (JavaFile javaFile : new SomeGenerator(fileDescriptors).generateValidatorFiles()) {
      writeJavaFile(javaFile);
}

I think a lot of this repeated code could be better simplified with a new interface:

public interface ValidatorGeneratorForFiles {
  Iterable<JavaFile> generateValidatorsForFiles(List<GtfsFileDescriptor> fileDescriptors);
}

and then code like:

ImmutableList<ValidatorGeneratorForFiles> generators = ImmutableList.of(new XYZGenerator(), ...);
for (ValidatorGeneratorForFiles generator : generators) {
  for (JavaFile javaFile : generator.generateValidatorFiles(fileDescriptors)) {
    writeJavaFile(javaFile);
  }
}

In that world, it's convenient to construct the generators separately from the file descriptors they'll ultimately be operating on.

Admittedly, that's the theory anyway. Looking at the existing generators, I acknowledge they all currently accept the descriptors via constructors. There's an argument that matches the "command" pattern, where each object encapsulates all the data it needs to executue.

But I couldn't help but look at that code and think it needed a refactor. For example, why do all the generators include their output package as a repeatedly defined static param. Stuff like that should be consolidated as well.

[maximearmstrong]

I agree with you. I think we can keep your code as is in that context. I opened an issue and linked this comment to it.

[maximearmstrong]

LGTM! Thanks @bdferris-v2