Chore: data types namespacing

[shark0der]

Context

#1121

Changes proposed in this pull request

Move enums and structs into their interfaces instead of having them at file level.
The ClaimMethod enum and the following structs that were left as is are because they're being referenced in other contracts.

ICoverProducts: ProductInitializationParams
IStakingPool: AllocationRequest, BurnStakeParams
IPool: SwapDetails, Asset
ICover: PoolAllocationRequest, BuyCoverParams, Product, ProductType, PoolAllocation, CoverData, CoverSegment

Note: There's also a workaround that can be used sometimes to avoid clashes in the future by importing only the desired symbols from the target file using the following syntax: import { IIndividualClaims } from "./IIndividualClaims.sol";. This way the Configuration struct wouldn't be imported. This won't always work, for example if you import two files while both are importing of everything from IIndividualClaims.sol.

Test plan

Used the following script to generate a file that imports all interfaces:

cd contracts/interfaces
for i in *; do echo "import \"../../interfaces/$i\";"; done | grep -v IERC20.sol > ../ImportEverything.sol

IERC20 is excluded because of the ^0.5.0 pragma which breaks the import as there's more than one IERC20: one for 0.5 pragma, one for 0.8.

The generated contract compiled fine but I don't feel like it's a good idea to add it to git because:

1. It needs to be constantly updated as we add new contracts
2. It's not bulletproof - there can be still structs in other files (besides interfaces)

So instead of slowing down the compilation with newer files we should rather watch out for these issues when reviewing PRs.

Checklist

• Rebased the base branch
• Attached corresponding Github issue
• Prefixed the name with the type of change (i.e. feat, chore, test)
• Performed a self-review of my own code
• Followed the style guidelines of this project
• Made corresponding changes to the documentation
• Didn't generate new warnings
• Didn't generate failures on existing tests
• Added tests that prove my fix is effective or that my feature works

Review

When reviewing a PR, please indicate intention in comments using the following emojis:

• 🍰 = Nice to have but not essential.
• 💡 = Suggestion or a comment based on personal opinion
• 🔨 = I believe this should be changed.
• 🤔 = I don’t understand something, do you mind giving me more context?
• 🚀 = Feedback

[MilGard91]

LGTM