[#290] Add `Universum.Lens` module

[Sorokin-Anton]

Description

Problem: As in #290, we want to export lens-related operators like (^.) or (^?), but we don't want to depend on microlens or lens.

Solution: Implement those operators by ourselves, and export them in a separate module to avoid name conflicts. Remove those operators from Universum reexports.

Related issues(s)

Fixed #290

✓ Checklist for your Pull Request

Ideally a PR has all of the checkmarks set.

If something in this list is irrelevant to your PR, you should still set this checkmark indicating that you are sure it is dealt with (be that by irrelevance).

• [ ] I made sure my PR addresses a single concern, or multiple concerns which are inextricably linked. Otherwise I should open multiple PR's.
• [ ] If I added/removed/deprecated functions/re-exports, I checked whether these changes impact the .hlint.yaml rules and updated them if needed.

Related changes (conditional)

• Tests

  • [ ] 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:

  • [x] README
  • [x] Haddock

• Record your changes

  • [ ] I added an entry to the changelog (creating the Unreleased section if necessary) if my changes are visible to the users and
  • [ ] provided a migration guide for breaking changes if possible

Stylistic guide (mandatory)

• [ ] My commit history is clean (only contains changes relating to my issue/pull request and no reverted-my-earlier-commit changes) and commit messages start with identifiers of related issues in square brackets.

  Example: [#42] Short commit description

  If necessary both of these can be achieved even after the commits have been made/pushed using rebase and squash.

✓ Release Checklist

• [ ] I updated the version number in universum.cabal.
• [ ] I updated the changelog and moved everything under the "Unreleased" section to a new section for this release version.
• [ ] If any definitions (functions, type classes, instances, etc) were added, I added @since haddock annotations.
• [ ] (After merging) I created a new entry in the releases page, with a summary of all user-facing changes.
  • I made sure a tag was created using the format vX.Y.Z

[Sorokin-Anton]

@gromakovsky

1. It looks like you partially deleted deprecated stuff. I propose to delete all deprecated microlens stuff in this PR

Do we want to have _1, _2, etc in Universum.Lens? I like it and looks like we can just copy-paste the Field1 and other typeclasses.

What about microlens-mtl? I suggest just stopping exporting them, but maybe we still want them?

2. Since everything in Universum.Lens is now defined manually, I think tests are needed.

Ok will add this week

[gromakovsky]

Do we want to have _1, _2, etc in Universum.Lens? I like it and looks like we can just copy-paste the Field1 and other typeclasses.

AFAIU they won't be compatible with functions from lens or microlens, because they define their own Field1 and other classes. Also they seem to be less trivial and more cumbersome. I'd like to avoid excessive copy-paste and to keep Universum.Lens small, because the whole universum should be relatively lightweight (since it's just a prelude).

But my main point was that currently the code in this branch hardly makes sense: the main point of adding Universum.Lens is to have some lens-related definitions without any extra dependencies, but microlens remains a dependency. So I think all microlens stuff should be deleted prior to adding Universum.Lens. Also you deleted mentions of microlens from README, but it's still used.

[Sorokin-Anton]

Yes I was going to delete them after we'd agree to do so. Let's keep the current exports from Universum.Lens (no microlens-mtl, no lens for tuples). I'll do this, add tests and fix docs where needed soon

[Sorokin-Anton]

I should not change any version tags, right? We must be sure no 1.8.x release will happen after we merge this to master

[gromakovsky]

Yep, don't change the version, but please write about this change in CHANGES.md. The person making the next release is supposed to read the changelog and realize that the change you made here is a breaking one. You may also provide a Migration guide to make it clearer (the migration is to use either lens or microlens as a dependency).