that are necessary for `tapasco-debug` but break up the usually wanted
encapsulation of `libtapasco`, so they are guarded behind conditional
compilation if the non-default feature is activated.

Write the 1 to start the PE directly to the appropriate address in
the mapped memory. Using `libtapasco`'s API function to start a PE
is not possible because ownership of the `PE` struct has already
been taken and cannot be stolen back in the starting function.

Also leave some instructions on how to enable it again.

Debug mode is currently the same as unsafe mode due to libtapasco
not handling this case of access mode.
Additionally, the DMA Buffers, Interrupts, etc. are also allocated in
Monitor Mode which leads to the problem that you have to start your
other runtime twice. For this case I've added a comment in the help
section of `tapasco-debug`.

by removing unnecessary folders.

to make it unsafe again.

when parsing the timestamp of the bitstream generation.

from the cherry-picked commit from PR #279:
03d717e9

This requires the App state to hold the device for the reference which
makes unsafe mode effectively debug mode. But this is not a problem
because debug mode is in reality unsafe mode as long as the exclusive
access is not working correctly.

	- Adds unsafe method to directly access platform component memory
	- Simplifies usage of platform components with interrupts
	  if they follow the TaPaSCo PE conventions
	- NOTE: Does not return a Job as most operations such as memory
	  copy does not make sense for most platform components

As discussed in the respective PR #290
(https://github.com/esa-tu-darmstadt/tapasco/pull/290)
there are now three differenct access modes: Monitor, Debug, Unsafe.

This commit introduces command-line subcommands to choose the mode in
which to operate.
In `Monitor` mode nothing can be modified only another runtime
can be monitored.
In `Debug` Mode the argument registers can also be set interactively.
In `Unsafe` Mode the only difference to `Debug` Mode is that the driver
is released, so another host application can run in parallel.

See commit 59110746aa4f5aa5f2c5ea7ced8df2e4d2f4f956.

In order to implement a Monitor Mode where values can only be observed
in `tapasco-debug` the function in `libtapasco` which is used to acquire
PEs is modified to return non-mutable PE structs which do not need
exclusive access to the device.

This is a necessary change for `tapasco-debug` to be able to acquire a
PE in order to call its methods instead of directly starting a job on
that PE as it is usually the case.

This is the first commit for a work-in-progress effort on Issue #264.

Since `tapasco-debug` was removed in the v2020.10 release because the
ncurses-based UI was "quite flaky" you had to use two different Tapasco
workspaces to have the debugger still around while using the recent
Tapasco version.
This reimplementation of `tapasco-debug` is written in Rust and
uses the `libtui-rs` and `crossterm` crates for the terminal user
interface along with the new Tapasco runtime.

For the moment it provides a list of PEs which can be selected to see
the first 16 argument registers along with some generic bitstream and
platform information.
Writing to argument registers, starting PEs, dumping Local Memory is not
possible yet.

To integrate it into the build process of this repository it uses the
same mechanism to build using Cargo from CMake as PR #285.

[feature] Build TLKM in Tapasco workspace

[feature/libtapasco] Remove unused struct members, apply clippy lints and refactor FFI

This modifies `tapasco-build-libs` to make the kernel module inside the
build directory of the tapasco workspace instead of the repository where
the source code is located.
Also, the scripts to load a bitstream are changed to use the new path
for the kernel object.

21 cases reported by clippy.