Modified the return type of "getDataProviderById" method to BaseDataProvider.

Fix can be found at:
https://bitbucket.org/djoshi4/deepti-fork-igb/branch/IGBF-1206_Duplicate_Sites_Issue

Tested the solution for all cases except the quickloads with username and password. The fix passes all tests.

Somehow--some magical how--The table of data providers knows which data providers should be editable, and which should not.

The table's class assumes that editable is true. So if editable is not set in a data provider, then its assumed to be editable. If it has editable set to false, then it is not editable.
All data providers were read from the json file have 'false' in the editable field.
This is the case if the json node has isEditable="false", or isEditable="true", or isEditable is missing. Somehow the DataProviderConfig always gets editable=false, even if the json file says true. I can't find what makes the DataProviderConfig object, or how those objects get put into the ArrayList called dataProviders as a field in the IgbPreferences object.
I just know that somehow, by the time we call IgbPreferences.getDataProviders(), they all have editable=false, regardless of the isEditable tag in the json file.

Somehow, the process that reads in default IGB prefs always sets editable to false for the dataProvider, and the data provider table (the gui) assumes things should be editable=true, unless they are false. The user-provided dataProviders have no way to set editable, so ... we get the ideal functionality, so its not broken. So I think its ok to give up on this.

The migrateOldDataProviders() method was introduced in May 2015 immediately after substantial refactoring about the DataProvider class. It was intended to migrate old dataProviders ("servers") from IGB 8.3 to IGB 8.4.

This method includes a set of fixed urls that it prevents from transfering.

The attached document "isEditable.docx" provides some details about how the isEditable tag is/was used for the Data Sources table, and how the Data Sources table was able to correctly allow editing for user-provided data providers but not allow it for default ones.

The document can serve as an example of investigating and trouble-shooting code. However, the document says nothing of all the many dead-ends that were ruled out to get to this point.

My testing confirms that this story is now resolved. I am not able to reproduce duplication of QL sites when opening 9.0.1 after opening 9.0.0. However, I am able to see duplicate QL sites when running 9.0.0 after 9.0.1, but I am thinking that this is expected, although not ideal. I will run this question by the team to verify that this is expected, but for now, I am marking as closed.