FilterWheel Refactor

[micahwoodard]

Is your feature request related to a problem? Please describe.
Right now, the filterwheel class is messy especially in the yaml file. It would be nice to not have to list every filter as a subdevice of filter wheel since all the info is already contained inside the filterwheel.

Describe the solution you'd like
I'd like to remove the subdecive filters from the yaml but sill be able to call filter.enable(). The easiest solution I can think of is to input a function called something like unpack_filters that iterates through filters in filter wheels and create filter device objects. It would be called in the _create_device function in the instrument if the device type is an filter wheel.

Acceptance Criteria

• remove filters as subdevices of filterwheel
• still be able to call filter.enable() instead of going through the main filterwheel

[micahwoodard]

@adamkglaser I can also see changing the driver files of FilterWheel and Filter similar to the stage refactor (#25) so you would only have to pass in what slot the filter correlated to in the init of the filter. I like keeping filters as a subdevice of the filterwheel since it most closely mimics what we are doing for other devices like the stage and lasers. It feels weird to me to have a separate function to sort out filters within a wheel when we are doing something similar with the stages axes but in a different manner.