Restructuring the source code

[data-man]

Inspired by many other libraries:

• transform to header-only library
• move headers to new include/libunicode directory
• move tests to tests directory
• move tools to root directory

As result:

benchmarks
docs
examples
include
tests
tools
.editorconfig
.gitignore
CMakeLists.txt
LICENSE
README.md
TODO.md
pylintrc

[data-man]

@christianparpart before I start, I need your feedback. ⁉️

[christianparpart]

Oh F. Sorry. I will respond as soon as I am back at my PC. :)

[christianparpart]

transform to header-only library

I think that is not possible. Just by having a look
at ucd.cpp. The algorithms should mostly be templated anyways. But I do not see a gain in making
this lib header-only (are there any header-only unicode libs that do also include the UCD properties?)

move headers to new include/libunicode directory

I'm fine in moving them. But include/libunicode instead of include/unicode? I think i've to get used to that first, as I generally don't like having the prefix lib in header names, because for me (personally) that's kinda superfluous, as almost all of the includes are coming from libs.
I do understand that this sadly clashes with ICU libraries directory prefix, which is also unicode, so I may give up on my dream here :)

move tests to tests directory

I had that for a very long time, until one of my friends said that at the big G they also have all the tests right next to the implementation files, so you can quickly get to the tests instead of searching for them.

I do agree, that if this would be a header-only lib, then moving tests would make sense. But until now I don't think header-only does not give any gain (actually quite the other way around).

move tools to root directory

I usually kept my root dir clean, but I am fine with that - or what about /tools instead of /src/tools?

uc-inspect isn't as general purpose and user-friendly as I'd like it to be. I initially created that tool for debugging and understanding unicode sequences, but it also helps others for exactly that reason, so I think we should make this
CLI tool more prominent. Sadly getopt_long does not exist on Windows and my CLI API is in contour (and moving doesn't make sense) and I also do not want to depend on boost (program_options) in this library. I have no perfect answer to that yet.

benchmarks

oh that's an interesting one. should that be a directory with some results and scripts for rerunning them? I really like that idea. That should also help finding weak performance spots in this library and should be addressed.

tools

above you said you wanted to move tools to root directory, but yeah, let's keep them in tools/ (not src/tools) :)

[christianparpart]

I should probably merge the other PR...

[christianparpart]

The uc-inspect tool can be moved in a separate PR already.

I also plan to extract the CLI API from contour into its own header only library that will become its own repo here under the org namespace.

That way we can freely use the same CLI API in any executable and repo. :)

EDIT: p.s.: I was saying this because I was earlier complaining about my unhappiness in the CLI args handling in uc-inspect.

[christianparpart]

transform to header-only library

https://youtu.be/sBP17HQAQjk?t=318 I just found a very interesting point of view against header-only (actually partly overlaps with my thinking why header-only is not always best choice) :)