BUG: inst.copy() doesn't work if Instrument comes from module

[rstoneback]

Describe the bug
Instantiating an Instrument via inst_module or via platform and name produce slightly different Instrument objects. Going via inst_module keeps a module attached to the Instrument which breaks inst.copy() and things that depend upon that.

To Reproduce
Steps to reproduce the behavior:

In [21]:         inst = pysat.Instrument(inst_module=cindi_ivm_gsw.instruments.cindi_ivm, 
    ...:                                 tag='daily_update', 
    ...:                                 update_files=True, 
    ...:                                 clean_level=clean_level) 
    ...:                                                                                                                                              

In [22]: inst.copy()                                                                                                                                  
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-22-47a535ad34b3> in <module>
----> 1 inst.copy()

TypeError: can't pickle module objects

Expected behavior

In [26]: inst = pysat.Instrument('pysat', 'testing')                                                                                                  

In [27]: inst.copy()                                                                                                                                  
Out[27]: pysat.Instrument(platform='pysat', name='testing', inst_id='', clean_level='clean', pad=None, orbit_info={}, inst_module=None, custom=[], **{'sim_multi_file_right': False, 'sim_multi_file_left': False, 'root_date': None, 'file_date_range': None, 'malformed_index': False, 'mangle_file_dates': False, 'num_samples': None, 'multi_file_day': False, 'user': None, 'password': None})

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: [e.g. iOS]
• Version [e.g. 22]
• Other details about your setup that could be relevant

Additional context
Removing the inst_module does mean that repr would no longer work. Perhaps it is better to account for inst_module in copy alone?

[rstoneback]

I ended up handling the module objects in the copy method itself. The change to iteration code in v3.0 (to include a copy) meant that inst_module instantiated instruments couldn't iterate in a variety of configurations. Tests were expanded to include an inst_module instantiated Instrument.