Fixes numpy encoding errors

I don't even know where to begin describing this bug.

Here is the outgoing granule before encoding
```
{'domain': (10,), 'data_producer_id': '', 'connection_index': '',
'record_dictionary': {1: array([ 0.,  1.,  2.,  3.,  4.,  5.,  6.,  7.,
8.,  9.]), 2: None, 3: None, 4: None, 5: None, 6: None, 7: None, 8:
None, 9: None, 10: None, 11: None, 12: None, 13: None, 14: None, 15:
None, 16: None, 17: None, 18: None, 19: None}, 'connection_id': '',
'locator': None, 'type_': 'Granule', 'param_dictionary':
'9a1f8b57e7af41479d42ce0764ad4ec1', 'creation_timestamp':
1365446562.004057, 'provider_metadata_update': {}}
```

Here it is after encoding
```
><> {'domain': [10], 'data_producer_id': '', 'connection_index': '',
>'record_dictionary': {1: [0.0, 1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 8.0,
>9.0], 2: None, 3: None, 4: None, 5: None, 6: None, 7: None, 8: None, 9:
>None, 10: None, 11: None, 12: None, 13: None, 14: None, 15: None, 16:
>None, 17: None, 18: None, 19: None}, 'connection_id': '', 'locator':
>None, 'type_': 'Granule', 'param_dictionary':
>'9a1f8b57e7af41479d42ce0764ad4ec1', 'creation_timestamp':
>1365446562.004057, 'provider_metadata_update': {}}
```

The numpy array was converted into a list and it turns out it stemmed
from the IonObject's overloading the setattr which is dynamically
attached at runtime inside registry.py and the walker bypasses walk and
somehow converts the numpy array into a list because numpy has __iter__.

Dave F suggested we use walk here so I implemented it using walk and now
granules flow again without bugs.