ahf / tor Public

This patch removes the `sandbox_cfg_elem` struct and replaces it with a
smartlist of `smp_param_t` objects.

See: https://bugs.torproject.org/26374

See: https://bugs.torproject.org/26374

This patch removes the unused `SB_IMPL` enum as well as the `implem`
field from the sandbox_cfg_elem struct. These fields were never touched
in current tor.

See: https://bugs.torproject.org/26374

It's needed by main.c

Fixes bug 26662; bug not in any released Tor.

I am very glad to have written this script.

This commit won't build yet -- it just puts everything in a slightly
more logical place.

The reasoning here is that "src/core" will hold the stuff that every (or
nearly every) tor instance will need in order to do onion routing.
Other features (including some necessary ones) will live in
"src/feature".  The "src/app" directory will hold the stuff needed
to have Tor be an application you can actually run.

This commit DOES NOT refactor the former contents of src/or into a
logical set of acyclic libraries, or change any code at all.  That
will have to come in the future.

We will continue to move things around and split them in the future,
but I hope this lays a reasonable groundwork for doing so.

This is a very gentle commit that just lays the groundwork in the
build system: it puts the include files to build libtor-app.a into
src/core, and to build the tor executable into src/app.  The
executable is now "src/app/tor".

(Note that this is not believed to work, but we may as well have it
in the right place till we remove it)

Inline its contents (which were all includes) into or.h, and some of
its contents into other places that didn't include or.h at all.

This is temporary, until src/or is split.

Putting this in containers would be another logical alternative,
except that addresses depend on containers, and we don't like
cycles.

There might be a better place for it in the long run, but this is
the best I can think of for now.

There might be a better place for it in the long run, but this is
the best we can think of for now.

We need this for strcasecmp on (some) Windows build environments.

Fix from Gisle Vanem.

Per recommendation by Gisle Vanem

These were mostly cases where our previous macros had been casting,
and the values that we were trying to printf were not in fact
uint64_t.