Misc refactor

[diimpp]

Tried to collect BC changes in single PR.

Fixes #192
References #191

• Renames SequenceInterface to CreditMemoSequenceInterface (Like OrderSequenceInterface, InvoiceSequenceInterface)
• Makes CreditMemo number unique and issuedAt non nullable (In doctrine mappings, for the rest of the app it's already holds true)
• Rename sylius_refund_payment to sylius_refund_refund_payment (Table was named incorrectly)
• Splits CustomerBillingData customerName into firstName and lastName (As in Addressing\Model\Address, Customer\Model\Customer, Invoicing\Entity\BillingData)
• Change CreditMemo issuedAt to datetime_immutable (Note, that I've converted CurrentDateTimeInterface to CurrentDateTimeImmutableInterface due to phpstan unability to handle properly \DateTimeInterface in context of \DateTime and \DateTimeImmutable DateTimeInterface can be only ever implemented by DateTimeImmutable and Datetime, nothing else phpstan/phpstan#314 https://phpstan.org/r/d15041c9-a230-4b18-a627-fc859ea00838 )

[diimpp]

@lchrusciel Hi, sorry, it's still in work. I've moved PR from draft too early, because travis wasn't building properly, but it was the other issue.

[diimpp]

@lchrusciel @Zales0123 it's ready for review. Let me know if you have any questions.

This PR is in fact 6 unrelated PRs, so please review each commit separately. Only difference is last two commits, because last commit is a supporting hack for phpstan.

P.S. There is another problematic code, which is src/StateResolver (No can checks, non-idiomatic files placement, Order->state state resolver doesn't work for me at all, but I didn't look too closely at it yet), but I won't be looking at it for the moment.

Cheers,
Dmitri.

[lchrusciel]

Hey Dimnitri,
thanks for your contribution!
It seems ok to go with this implementation, but right now we don't have enough power to do a proper review here and possibly release a new version

[diimpp]

@lchrusciel thank you for update. I do plan to change Refund/RefundPayment/CreditMemo mappings drastically, so it may be worth waiting for next PR anyway.

Current implementation with Refund/RefundPayment/CreditMemo, which are not related between each other is not usable for my company. We need CreditMemo to be generated only after RefundPayment is completed. Another case, we need to different between Refund's as when they were done and how they were grouped and after the fact of the refund, not at the refund event itself. (Another point is just technically not feasible approach. Let's say event fails for whatever reasons, then Refunds are created, but CreditMemo/RefundPayment probably not. And there is no way to re-send this event.)

[Zales0123]

It looks very good 👌 Thank you @diimpp for such wonderful work, you're making the world a better place 🖖 🎉

[lchrusciel]

Thank you, Dmitri! 🥇