refactor: add "Lockup" prefix

[PaulRBerg]

Implements #261.

As discussed and agreed in #232, this PR adds the Lockup prefix to all relevant entities - contracts, structs, and events.

I ended up separating the lockup streaming logic from the administrative functions of the protocol because of one simple reason - it's a nice developer experience for the ISablierV2Lockup interface to contain only those functions that can be called by end users (as opposed to also containing such functions as setComptroller which are admin-protected).

Later on - if and when we implement the payroll contract - we can adjust the ISablierV2 to fit the new common functions between all contracts. Interfaces can be updated even retroactively.

Update - if you don't like the name of the LockupCreateAmounts struct (as I don't now), don't worry, I have refactored it in a later PR (see #284).

[andreivladbrg]

The constructor is not tested in SablierV2(MAX_FEE and comptroller).

we can adjust the ISablierV2 to fit the new common functions between all contracts. Interfaces can be updated even retroactively.

If we plan on doing this, it would be better to rename the actual ISablierV2 to something like ISablierV2Administrative, to be able to inherit it in the future common "ISablierV2" interface, and implicitly in the payroll as well.

if you don't like the name of the LockupCreateAmounts struct (as I don't now), don't worry, I have refactored it in a later PR (see TODO).

Yes, I don't like it either. It is also redundant to have a LockupAmounts in the LockupLinearStream and LockupProStream structs.

[PaulRBerg]

The constructor of SablierV2 is implicitly tested in the constructor tests of SablierV2LockupLinear and SablierV2LockupPro.

rename the actual ISablierV2 to something like ISablierV2Administrative

I'm not against this but finding a good name won't be easy - in fact, this is why I used ISablierV2. Can you open a discussion about this, please?

It is also redundant to have a LockupAmounts in the LockupLinearStream and LockupProStream structs.

I added that struct as part of my painstaking effort to get rid of StackTooDeep in #220 - so it is not redundant, not at all.

The amounts struct also provides type encapsulation - i.e. grouping of similar struct fields under the same "roof".

[andreivladbrg]

I added that struct as part of my painstaking effort to get rid of StackTooDeep in #220 - so it is not redundant, not at all.
The amounts struct also provides type encapsulation - i.e. grouping of similar struct fields under the same "roof".

I was just referring to the names. LockupAmounts is used only in LockupLinearStream and LockupProStream structs, the word "LockUp" is repeated and it is unnecessary.

[PaulRBerg]

Oh, I see, thanks for clarifying!

There's a reason why I used the Lockup prefix, and I argue it is a good reason. That is, we have to think about the V2 protocol as a set of smart contracts that each has different streaming logic. And "amounts" is probably something that all streaming contracts will have. To avoid an ugly namespace clash in the future (when we get to implement what we currently refer to as the "payroll contract"), I have to decided to preemptively add the Lockup prefix.

We may end up never needing another Amounts in other contracts, but we can't know that right now. The cost of adding the prefix isn't high.

[PaulRBerg]

@andreivladbrg let me know if the PR is good to be merged now.

I have addressed all of your comments, except for those related to the names of the scripts and CI workflows, which I have fixed in #284 (re-fixing them here would tigger a cascade of git conflicts).

[PaulRBerg]

@andreivladbrg, just so you know, I tested all the values initialized at construction time in PR #284.