Standardise parameters naming and validators

Nobody has claimed this yet.

Following from #139. We have few issues that nee to be solved at once and for all :P

The first issue at hand is, given the parameter foo:

``` python
>>> foo.status('on')
# vs
>>> foo.status(1)
# vs handle everything internally, accept most inputs
>>> foo.status("bar")
```

I would pick shortest, lower case string.

then

``` python
foo.ground
# vs
foo.Ground
```

I would just pick all-lower case, because easier simpler, more predictable (albeit less scienc-y).

Last about f.ex.

``` python
foo.status = True
# vs
foo.status = "running"
```

Some how I think that a lot of things can be "booleanized", but I don't know what you scientists want.

I would like foo.is_running-->bool, rather than foo.status--> "too many options will break eventually".
It may be less sexy and look less clever, but it's just miles easier. But just IMHO.

Now, fight! @alexcjohnson @AdriaanRol @spauka @MerlinSmiles .

Start by reading the linked discussion in #139 and the parameter examples in this issue. Determine which naming, accepted-value, and booleanization conventions the project should adopt, then identify the affected parameter APIs. Done requires an agreed convention and consistent implementation, but no files or tests are named here.

Written by the indexing model from the issue text.