Ref:

    https://bugzilla.redhat.com/show_bug.cgi?id=1586291#c1

Turns out this was a silly idea: the %{dist} flag needs to stay there
for the final builds.  What I wanted to achieve was just remove it from
version as reported in COPR. (Not sure if that is even possible.)

This reverts commit 2f1ea384362d52c7d8c886a5a3ea7aa09509cef6.

Not useful (even confusing) in case of COPR builds

Two things have been changed in upstream: build system now properly
places 64-bit .so under %{_libdir}, and the .so itself now contains
versioned SONAME.

This means we can remove workaround for the first issue and start
packaging library separately.  This is much closer to FPG than before.

Ref.: https://github.com/naelstrof/slop/issues/86#issuecomment-328479278

Hard-code COPR project names and switch them as well as prefix Release
tag based on mode.  This prevents from confusing builds.

Most of the time we want to anyway, and it's easy to interrupt if
needed.

It was moved to slop subdirectoty in attempt to get rid of rpmlint
warning concerning non-standard soname:  this would make 'libslopy.so' a
"private" library, for which naming is not mandatory.

However, this actually breaks slop binary!

Turns out there's no way around it.  What we could do is, in order of
preference:

 1. Solve naming issue with upstream.

 2. Just call it libslopy.so.1.

 3. Use wrapper to add %{_libdir}/slop to LD_LIBRARY_PATH

(The last thing seems really like a too hacky for such simple utility.)

Since libslopy is considered private, there should not be need for
header file.