[feature request] load mavproxy modules from an external package

Modules are currently loaded from the `MAVProxy.modules` package. This ticket (feature request) is to support loading them from other (arbitrary) packages on the system. There are two use-cases:
- keep local customisations independent of the MAVProxy tree
- avoid circular dependencies, such as those currently between MAVProxy and cuav

This feature would probably keep the current load path as a default, but also allow the user to specify an alternative load path with some kind of option. e.g. rather than

```
MAV> module load FOO
```

which assumes the module is either installed as:
- MAVProxy/modules/mavproxy_FOO.py; or
- MAVProxy/modules/mavproxy_FOO/**init**.py

We might also do this:

```
MAV> module load BAR::FOO
```

which would load the module from either:
- BAR.mavproxy_FOO.py; or
- BAR.mavproxy_FOO/**init**.py

Where BAR could be any installed package (on the PYTHONPATH of the interpreter running mavproxy).

The current module load path is hard-coded in mavproxy.py:851

psudocode for changes in the vicinity:

```
if module_source is not specified:
loadpath = "MAVProxy.modules"
else:
loadpath = module_source
(but raise an error if loadpath is unloadable)
load "%s.mavproxy_%s" % (loadpath, module_name)
```

Plus of course changes to the checks on number of arguments, etc.

Question: what syntactical sugar to use?
- load module BAR:FOO
- ??? other ideas / suggestions?

Note to self: remember to test scenario where BAR::FOO and BAM::FOO are both being loaded/unloaded contemporaneously. i.e. don't mix them up, preserve namespaces.

Start at mavproxy.py:851 and trace the module load command, including its argument-count checks and current MAVProxy.modules import path. Decide and document the external-package syntax, then verify default loading, unloadable-package errors, and concurrent BAR::FOO and BAM::FOO load/unload behavior without mixing namespaces.

Written by the indexing model from the issue text.