Cleaner External Device Referencing

[MikeHart85]

This came up while reviewing #259.

Currently, Lewis requires this sort of layout for a custom device directory:

/some/host/path         <-- Must point -a here
├─ devices/             <-- Must name this using -k
│  ├─ epics_device/     <-- Must name this as positional argument
│  │  └─ ...
│  ├─ stream_device/
│  │  └─ ...
│  └ __init__.py        <-- Must exist

From an internal implementation perspective, I understand why this is the case. But from a user's perspective, this is all very counter-intuitive, strange and inconvenient... because a user will be looking at it this way:

/path/to/my/devices   <-- Lewis needs to know where my devices are
├─ epics_device/      <-- Lewis needs to know which device I want to start
│  └─ ...
├─ stream_device/
│  └─ ...
└ __init__.py         <-- Why do I have to add this? Shouldn't be necessary!

I have some devices. I've put them all in a folder.
I understand Lewis needs to know where they are and which one to start. But...
Why is /path/to/my/devices split into two options?
Why does Lewis even care about /path/to/my? That has nothing to do with my devices/!
Why do I have to put this weird __init__.py thing in path/to/my/devices? It's just a folder where I happened to put my devices!"

I think a cleaner syntax would be something like:

$ docker run -it -v /path/to/my/devices:/external dmscid/lewis -m /external epics_device
$ lewis -m /path/to/my/devices epics_device

Or maybe we could even integrate path detection with the device name parameter (If a / or \ is present, treat device_name as a path/to/device_name):

$ docker run -it -v /path/to/my/devices:/external dmscid/lewis /external/epics_device
$ lewis /path/to/my/devices/epics_device

[MichaelWedel]

I mostly agree with this...after having written a few "external devices" this has become quite inconvenient.

The only part I am not so sure about is whether it's possible to import stuff in the absence of an __init__.py. I guess a good start would be to cut out the -k option (easy to remain backwards compatible - could just be appended to whatever else we decide to call the "new" option).