Allow users to organize procedures and functions freely

[uxmal]

Today, reko allows users to rename functions to more meaningful names than
fn01231230. These renamings are stored in the *.dcproject file. In
issue #73 I discuss output file organization, where output files are defined by
the binary executable sections/segments.

Iit would be beneficial for the user to also be able to reorganize functions
(and global data) into files that she has defined herself. Assume that reko has
been fed foo.exe; after decompilation. I propose the following in the GUI:

foo.exe
+- x86 real mode
+- MS-DOS
+- Image
+- 0800
   +- fn0800_0000       # the first procedure found in segment 0800
   +- fn0800_0134       # the next procedure, and so on...
   ...
+- 1E71
   +- fn1E71_0000       # first procedure found in segment 0800
   +- close_all_files   # procedure was renamed by user.
   ....

Here we see the files appearing under the segments (and therefore, according
to #73, files) that they would appear under. The user could add output files to the
project, including any arbitrary folder structure:

foo.exe
+- x86 real mode
+- MS-DOS
+- Image
+- 0800
   +- fn0800_0000       
   +- fn0800_0134       
+- 1E71
   +- fn1E71_0000
   +- close_all_files   
+ io                    # user-created folder for placing IO files.
  +- fileio.c           # user-created file for placing file IO routines.

Now the user can drag close_all_files into the fileio.c file:

foo.exe
+- x86 real mode
+- MS-DOS
+- Image
+- 0800
   +- fn0800_0000       
   +- fn0800_0134       
+- 1E71
   +- fn1E71_0000
   +- (close_all_files) # procedure grayed out, indicating it's been moved
+ io                
  +- fileio.c
     +- close_all_files # new location of the procedure

If all procedures are dragged out of segment 0800, reko won't generate a foo.0800.c file.
User should be able to revert the location of a procedure back to the originating segment/section
if they wish.

[nemerle]

Basically tagging each function with it's intended 'source-tree' location ?
I like this very much, especially since some executable formats have this kind of data embedded in debugging segments.

[uxmal]

That's exactly right. Once reko acquires debug symbol-reading capabilities, it would fit in very nicely with this feature.