[TM-309] Move Lorentz code into a new package

Description

Problem: Over time some morley package became bigger and it seems that now is a good time to draw some boundaries between its parts. The main reason is that if a package contains X and Y while someone needs only X, they will be forced to depend on Y as well. Also it makes dependencies inside this repo more explicit and clear.

Solution: create morley-lorentz package and move Lorentz code there. I had to move some utility testing code used by Lorentz tests to morley lib or to morley-lorentz (if it is used only by morley-lorentz). Test.Tasty.HUnit now exists in two places, it will be resolved in TM-268. Also I moved tOriginate, tTransfer and tExpectStorageConst to Michelson.Test.Integrational because they do not use anything from Lorentz.

Some difficulties arose because some tests in morley use Lorentz. They were solved as follows:

1. Test.Integrational was rewritten using Michelson.Typed instead of Lorentz.
2. Doc.hs and DocTest.hs tests were moved to morley-lorentz because they are heavily based on Lorentz. Also Lorentz.* tests were moved there.
3. Test.Interpreter was split into two Test.Interpreter modules (in different test-suites). In the next commit we will clean it up.

Another notable change is movement of Arbitrary instances for UStore types into UStore.Types module. As a bonus it removed 2 orphan instances.

Related issue(s)

https://issues.serokell.io/issue/TM-309

✅ Checklist for your Merge Request

Related changes (conditional)

• Tests (see short guidelines)

  • If I added new functionality, I added tests covering it.
  • If I fixed a bug, I added a regression test to prevent the bug from silently reappearing again.

• Documentation

  • I checked whether I should update the docs and did so if necessary:
    • README
    • Haddock
    • docs/
  • I updated the changelog if my changes are externally visible.

Stylistic guide (mandatory)

• My commits comply with the following policy.
• My code complies with the style guide.