Consider separating browser and element classes from core/entity.py file into their own files for more intuitive use

[MatuMikey]

I'm a fairly new user to this selene project and found it odd that these two classes, which perform separate tasks altogether, were part of the same file and thus had the same import. Further to that effect, I actually had trouble finding where to import a browser/element class due to this naming convention.

I personally find it more readable and intuitive to import a browser from a file that is dedicated to Browser functionality only.

Final motivation is that it reduces the amount of code one needs to read through in a single file when trying to understand how to use the methods associated with the class - having multiple classes in the same file may confuse a user as to their usage.

[yashaka]

Probably, historically, all these classes happened to live one file because of some "recursive imports" problem, that we had in the past... But maybe that problem could be fixed still by having these classes separated into different modules...

Another reason why those classes live together, might be: they all are "entities" sharing same API by extending the corresponding bases classes... But we still can have those api in something like entity.py, then have separate modules to keep each corresponding extension of such API: element.py, collection.py and browser.py with the corresponding classes Element, Collection, Browser. Probably you are right in context of "reduce amount of code to be read through in a single file" and it would be good to refactor current implementation correspondingly...

Nevertheless, when using Selene in some automation project, the best way to import those classes would be simply via:

import selene

browser: selene.Browser = Browser(Config(...))
button: selene.Element = browser.element('#submit')
results: selene.Collection = browser.all('.result')

or

from selene import Browser, Element, Collection

browser: Browser = Browser(Config(...))
button: Element = browser.element('#submit')
results: Collection = browser.all('.result')

also... there is one nuance in context of browser management...

probably we will have two classes to represent Browser: selene.Browser and selene.managed.Browser. The first one - is the one, currently living in selene.core.entity.py. The second one - lived previously as selene.support.shared.browser.Browser. The first one is pure "browser with access to simple driver instance via Config(driver=...)", the second one is a "browser with automatic driver management"... The corresponding work is in progress under umbrella of #406

Recalling #406, probably eather I will break down entity.py into entity.py, element.py, collection.py and browser.py in context of #406, or once #406 is done I ask you or somebody else to finish this break down...