Better Composer

[dxoigmn]

What does this PR do?

• Make Composer an nn.Module.
• Think more carefully about Composers vis-a-vis universal composers versus sample-specific composers.
• Make Composers actually composable instead of inheriting from each other. A good first start is turn Composer into an nn.Module.

Type of change

Please check all relevant options.

• Improvement (non-breaking)
• Bug fix (non-breaking)
• New feature (non-breaking)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

Testing

Please describe the tests that you ran to verify your changes. Consider listing any relevant details of your test configuration.

• Test A
• Test B

Before submitting

• The title is self-explanatory and the description concisely explains the PR
• My PR does only one thing, instead of bundling different changes together
• I list all the breaking changes introduced by this pull request
• I have commented my code
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• I have run pre-commit hooks with pre-commit run -a command without errors

Did you have fun?

Make sure you had fun coding 🙃

[dxoigmn]

@mzweilin: i could use your help on thinking about how to compose composers. the problem i'm seeing is that some composer want to modify the input and others want to modify the perturbation. right now, composers only returned a new input so there's no way to propagate changes to the perturbation.

some changes to perturbation are independent of the input, but others are not (e.g., resizing the perturbation to the size of the input). it's worth keeping in mind the use case in #132.

[dxoigmn]

We can also just not worry about composition of composers.