Reconsolidate SWIG specification from multiple sub-specs

See merge request !1

There are otherwise seemingly unresolvable linking issues when the
spec is split into three sub-modules.

Require re-writing the pkg/ wrappers to match the new top-level mosh
internal package.

Required fixing the relative import statements within pkg.

Also bumped the upstream submodule reference for mosh to include
a recent bugfix.

Ready to test and try using this library.

With these build.go files providing CGO specifications, the overall
build process of all of the wrapper packages succeeds and automatically
invokes SWIG as part of the 'go build'.

Main remaining task is adding a way to fetch the Mosh version string.

Not clear how to use anything in the wrapper when built this way, however.

The mosh class wrapper implementations are now namespaced with
Go packages in the same structure as the underlying wrappers.

This allows successful build of libparser.so, and should be
valid on both macOS and Linux.

Had to add inclusion of libncurses and libprotobuf, as well as
the hostinput protobuf output.

Both compilation and linking (into a shared library) of the overlay
(specifically the Overlay::PredictionEngine class from mosh) package
now succeeds with a set of Makefile modifications.

The parser package almost succeeds, but the terminal package still
has some work required.

Had to rerun 'make' in the mosh/src/protobufs directory to recreate
the generated code. This requires a precise match to the system
installed version of protobuf, and apparently I had updated between
building mosh and trying to build these wrappers.

Was not able to actually compile mosh_wrap.cxx that was generated
from mosh.i, due to both include path and linking challenges.

Decided to break the SWIG declarations into three separate files,
with one for each namespace, and added pseudo-Makefiles for each
of these three implementations that produce nearly(?) working
wrapper artifacts.

The mosh project structure requires a complex set of extra
include paths, which is captured by those Makefiles, and the three
generated wrappers succeed in that phase.

The manual expression of extra linking objects still needs some work.
The main errors from the wrapper compilation processes now appear to
be caused by issues with the Protobuf dependency of mosh.

Once these issues are better understood, the goal would be to convert
these Makefile encoded parameters to the C++ compiler into the format
expected by cgo comments. If done correctly, the cgo documentation
suggests that SWIG will be invoked automatically, and all of the
required objects should also be automatically incorporated into the
build process for the final consumption by Go.

These seem to be const references in the C++ implementation. Likely, these will
refer to wrapped internal Framebuffer instances that were explicitly created and
passed to the Complete instance. As such, no finalizer is attached to these
references.

If this analysis is correct, it is possible to retain dangling pointer references
to these Framebuffer instances if the parent reference is finalized. To correct
this otherwise would require some kind of reference counting.

These wrappings should be adequate for using the prediction engine.

An open question remains about GetFramebuffer of Terminal::Complete:
should the returned Framebuffer be owned by the caller of the function,
or should it be attached to the associated Terminal::Complete instance?

Also started to implement wrappers around the two relevant Parser::Action
sub-classes.

Had to add an 'apply' directive to SWIG to fix some uint64_t to
uint64 issue.

The Go backend of SWIG does not support C++ smart pointers. Fortunately,
the should be OK to treat as opaque pointers, so long as they are not
accessed from Go code.

Determined the subset of C++ classes required for export
and began a more focused SWIG specification. Have one major
problem remaining with std::shared_ptr support.

Most of the code of interest is under 'mosh/src/terminal',
though there is also code under 'mosh/src/frontend' including
prediction engines and overlays that this may need too.

This will be a SWIG based wrapper around Mosh so that it can be used as a library from Golang.