Remove "irtk" prefix from file names when headers are installed in "irtk" subdirectory

[schuhschuh]

This is a low priority issue. But generally I would like a project to choose either to prefix all (header) files with a project-specific prefix such as "irtk" and install the files in the top-level include directory, or use a meaningful subdirectory structure with the project name as top-level subdirectory. That is the current approach now for module header files and I prefer it as well. But in this case, I would like to get rid of the archaic "irtk" prefix in file and class names (after moving to an "irtk" namespace instead).

[ghisvail]

Renaming the public headers implies breaking the inclusion API. Do we want users of existing code to have to change all their includes and use the appropriate namespace, only for cosmetic reason ? This is a decision not to be taken lightly, just saying.

[schuhschuh]

Do we really have (m)any users of IRTK as a library? Because of this, we should make such decision now that we anyway break with the past by replacing entire modules with new implementations (i.e. transformation and registration...). The IRTK thus far has not been a library, but a collection of command-line tools. As noted at many occasions, now is the chance and time to restart this project with proper up-to-date best standards. There is no such thing as "backwards compatibility" here. We break it in any case. Many choices made for IRTK more than 10 years ago (e.g., to not use the const keyword as VTK does/did at the time) are as outdated as those for ITK <4 and VTK <6 were. And those much larger projects have decided to break backwards compatibility even though this affected a large user base. A user base the IRTK is just now hoping to attract.