Cleaning up include file inconsistencies

[Dr. Matthias St. Pierre]

I am beginning to  wonder whether it is a good idea to make the fact
whether a private header file contains exported symbols as selection
criterion for where the header file needs to go in the source tree:

> >  - headers in `include/internal`
> 
> For internal things that we want to make available for both libcrypto
> and libssl (i.e. they are exported in libcrypto.so)
> 
> >  - headers in `crypto/include/internal`
> 
> For internal things that we only want available inside libcrypto
> (i.e. they are NOT exported in libcrypto.so)

If you take a look at commit d5e5e2ffafc7 (Move digests to providers)
then you will notice that the `sm3.h` header file was moved:

    ~/src/openssl$ git show --stat d5e5e2ffafc7 | grep sm3.h
    {crypto/include => include}/internal/sm3.h         |   7 +-

So it seems like whenever the first symbol of a libcrypto-only private header file
needs to be exported then we also have to move the entire header file?
This is tedious and also doesn't really make sense. Because now the files sm2.h
and sm3.h happen to be in two different directories:

    crypto/include/internal/sm2.h
    include/internal/sm3.h

To be precise: that's only in master, because in 1.1.1 they are still in the same directory.
(That's how I noticed it in the first place, because I compared source trees.)

My suggestion instead would be to store all internal header files which are shared by
more than one sub-system either in

    include/internal/crypto          ( #include "crypto/filename.h")
    include/internal/ssl                 ( #include "ssl/filename.h")

depending on where the code is *implemented*, not where it is *used*.
The directory `include/internal` itself should not contain any include files.

Whether an internal libcrypto function can be used in libssl should depend only
on libcrypto.num and nothing else.


Matthias