get rid of hdp files and generation of these

[hannesm]

they are deprecated and have no reason for being around - use lid instead!

[hannesm]

so actually they aren't deprecated - but should contain only the local state - like saved breakpoints - application arguments, etc. - and they should contain the complete lid file (and if there's no local state, they should be non-existing)

[cgay]

I think they shouldn't contain the entire .lid file, they should just augment it. They could reference it via the existing LID: header.

Need to write down exactly what the differences are between <dfmc-lid-project-object> and <dfmc-hdp-project-object>. My rudimentary understanding is that, as Hannes pointed out, they contain local state (generated by the IDE only, I think) and they have "subprojects" entries that have relative links to other project files so that registry entries aren't necessary. The latter is useful in the IDE but as soon as you want anyone else to use your project it needs registry entries. (This is now handled by dylan-tool.)

Seems like it would be useful to have some sort of hierarchical project naming scheme to prevent the need for either of these schemes and get away from a single, flat registry namespace?

[cgay]

One thing I realized while adding protobuf support is that the .hdp file is augmented with new source files that are generated by build tools (motley, scepter, protobuf). So, specifically, the Files: header can contain more files than the same header in the corresponding .lid file.

Also, if we need them at all, wouldn't it make sense to store them in _build/build/my-lib/ instead of dumping them in my source code?