JSON topology improvements

[guruofquality]

From @guruofquality on January 7, 2015 11:9

• Support hierarchies of JSON topologies. A block config could point to another JSON file which contains a JSON topology. We would just instantiate a connect another topology from this config (recursive).
• Parameterize the topology. The markup should have a list of configuration parameters. These parameters are refered to by name in the block config arguments (like variables). The configuration parameters may have a default, but they can also be varied by 1) passing in options on the PothosUtil command line or 2) passing them in through the block config (see support hierarchies).
• Make it easier to install JSON topologies into the property tree. Consider that the user may want to express the block description for the GUI (which also has a JSON representation). Installing and locating JSON resources at runtime.
• PothosUtil topology executor should have an option to dump stats at the end of the run into a json format. This completes a benchmark runner app where test sets and results can be handled in a high level language like python -- and plotted. This should really be a new issue on Pothos::Topology to dump JSON stats for all blocks in the topology.
• The Pothos::Topology should parse the GUI's JSON format as well.

Copied from original issue: pothosware/pothos-library#86

[guruofquality]

Make it easier to install JSON topologies into the property tree

This would be another good use case for the conf-file based block registry. Where users install JSON described sub-topologies as blocks which are referenced by the global conf register so they are visible as any normal block would be for the block registry API and GUI.

PothosUtil topology executor should have an option to dump stats at the end of the run

This should work with --output=outputFile

The Pothos::Topology should parse the GUI's JSON format as well.

Issue for exporting to this format: pothosware/PothosFlow#114