Install locations in packaging

[gtrepta]

The ubuntu package installs into some strange paths and has files that don't belong in it.

• We install /usr/lib/scripts/util.sh and /usr/lib/version, which have no indication on first glance of what package they're a part of.
• We install a bunch of headers into /usr/include/fmt, sharing ownership over those files with the libfmt-dev package.
• Some files that go to /usr/bin either shouldn't be there (ng, booster-dev, eventlog-parser?) or need to be named better (rpc-client)

A rough outline of folders created under /usr by the package:

usr
├── include
│   ├── fmt
│   ├── kframework
│   ├── kllvm
│   └── kllvm-c
├── lib
│   ├── cmake
│   │   └── kframework
│   ├── kframework
│   ├── kllvm
│   └── scripts
└── share
    ├── doc
    │   └── kframework
    └── kframework

IMO it should look like this:

usr
├── include
│   ├── kframework
├── lib
│   ├── cmake
│   │   └── kframework
│   ├── kframework
└── share
    ├── doc
    │   └── kframework
    └── kframework

[dwightguth]

The /usr/lib/kframework and /usr/include/kframework directories were created for this purpose. We can move scripts and fmt under the respective directories.

[F-WRunTime]

Here is the debian Directory Tree definitions / standards @gtrepta

https://www.debian.org/releases/buster/amd64/apcs02.en.html

[gtrepta]

#3683 Has been drafted to move /usr/lib/version.

My next step is to move the llvm-backend under /usr/lib/kframework. This will clean up a lot of the filesystem. However, this will require putting the llvm-backend's binaries under /usr/lib/kframework/bin and symlinking to them from /usr/bin. I have to open a PR for the llvm-backend first to make it more tolerant towards these symlinks (runtimeverification/llvm-backend#848).

Further work ahead:

• The FHS states that /usr/include is for C language files. So, I think it's a good idea to move include/kframework to lib/kframework/include
• Audit the binaries installed to /usr/bin for any that should be moved to /usr/lib/kframework/bin

[Baltoli]

We should maybe move the ng binary out of the default binary search paths.