message: updated  packaging documentation with formatting and mistake fixes
diff: ## Code Structure
  -This pip package branch builds upon updated directory structure for concise import paths. All the modules are now sub-module of main bark module, and are imported w.r.t it. C++ python bindings previously in python folder are now in python_wrapper folder under bark main directory and similarly components from module directory are also placed under bark directory. C++ python library is renamed `core.so` from `bark.so`.
  +This guide describes the updates to bark probject as part of pip packaging work and builds upon **bark** with updated directory structure for concise import paths, along with other changes and updates required for the packaging process.
  +All the modules are now sub-module of main bark module, and are imported w.r.t it. C++ python bindings previously in python folder are now in python_wrapper folder under bark main directory and similarly components from module directory are also placed under bark directory. C++ python library is renamed `core.so` from `bark.so` and all modules imported from the C++ library are under bark.core.*.
  > The import paths have been updated from following
  @@ -12,7 +13,7 @@ This pip package branch builds upon updated directory structure for concise impo
  `from bark.world import World`
  `from examples.*`
  -> To a more concise format as
  +> to a more concise format as
  `from bark.runtime.commons import ParameterServer`
  `from bark.core.world import World`
  @@ -66,7 +67,7 @@ After successful completion of tests, the package is built using
  > Note: The above command automatically identifies if the code is pure python package, in which case the package is available for all platforms and configurations. In our case we make use of locally compiled thus platform dependent`core.so` shared library(exposing C++ functionality of Bark API) .
  > But as the Library is not compiled using `setup.py` script so the script does not identify the shared library and considers the package as a standard python package. Adding an extra empty extension under `ext_modules` instructs the package building code to mark the wheel file as a platform dependent code, thus generating a wheel file for the specific build platform.
  > Therefore, when installing the package using `pip install ..` the pip will pick the appropriate wheel to install.
  -> This approach works for non Linux distributions only as setup.py generates literal platform specific versions for non Linux OS's while for all the Linux distros it generates a generic linux_x86_64 tag, which is rejected by PyPI repository. For Linux, the [PyPI standard](https://packaging.python.org/specifications/platform-compatibility-tags/) requires that a standard docker image called [manylinux](https://github.com/pypa/manylinux) be used for building the wheel.
  +> This approach works for non Linux distributions only as setup.py generates literal platform specific versions for non Linux OS's while for all the Linux distros it generates a generic linux_x86_64 tag, which is rejected by PyPi repository. For Linux, the [PyPi standard](https://packaging.python.org/specifications/platform-compatibility-tags/) requires that a standard docker image called [manylinux](https://github.com/pypa/manylinux) be used for building the wheel.
  > The process for building pip package in the specified docker container has some complications caused by Bazel support along with C++ libraries. so the current approach is to have version specific wheels for Mac OS and a generic wheel for Linux based systems that is build on Ubuntu 64. It shall not work with all of Linux distros but shall be compatible with most of debian based architectures.
  Once a wheel is built, it can be uploaded to PyPi repository.
  