[Stk] proposal for stk git repository layout

[Stephen Sinclair]

Hello all,

I have been working on my STK git repo, and I hope it is closer to
what might satisfy everyone.

The "master" branch is the main development branch.  It includes
purely source files such as "configure.ac", ".cpp" and ".h" files,
etc.  It does not contain the output of autoconf or doxygen, since
these are generated files.

The "releases" branch contains branches off of "master" for each
release.  In this branch, the generated "configure" and html
documentation are included.  For each "tarball" commit under
"releases", there is a tag associated.

This is illustrated in github's network view:
https://github.com/radarsat1/stk/network

The upshot is that there is a clear link to the development branch for
each release, and meanwhile if one browses to the github "releases"
page, which presents a download link for each tag in the repository,
one sees each release listed there:

https://github.com/radarsat1/stk/releases

If someone downloads 4.4.4, for example, they will get a file called
"stk-4.4.4.tar.gz", and he/she only needs to type "./configure &&
make" to build STK.

Meanwhile we can continue development in the "master" branch without
interference and history-confusing changes due to autoconf and
doxygen, etc.

A few decisions had to be made:
1. what to do with the disappearing "Debug" and "Release" folders
2. should "config.sub", "config.guess", and "install.sh" be included?
3. remove any files that shouldn't have been in the release tarballs?

1: I decided to add .placeholder files so that the Debug and Release
folders are there just as in the tarball releases.  As of commit
8d2e9d9cf, which patches Makefile.in to create these directories if
they don't exist, the .placeholder files are removed.

2. I wanted to remove these as they are part of autoconf/automake and
should be available on the developer's system, but in the end I found
that even after running "autoconf", the configure script would not run
correctly without these files present.  I left them in the repository,
but perhaps if we move to automake/libtool in the future it won't be
necessary to keep them.

3. Any .o, *~, ._*, .DS_Store, etc.. files were removed before any
commit to the repository.  Same for a few Mach-O and ELF executables
that were in some release tarballs. (Mainly the projects/* folders)

So, still to deal with is how RtAudio and RtMidi should be handled.
i.e. as separate projects or what.. I'll leave that for a little
later, as it is after midnight now ;)

My inclination is to keep them in the same repository as STK but
generate different "tags" containing different subsets of the files
depending on which software is being released -- this could work
great, but has to potential to get a bit confusing -- though nothing
that we couldn't make easy with some simple scripting.  The
alternative is to have 3 separate repositories.  Then there's the
question of using git submodules or not.

Steve