Change interface for operator to be on the module level instead of the class level

[benthayer]

Opening just for the purpose of documenting. We had a discussion on whether it makes sense to have an operator class that is instantiated with the same variables every time we need an operator because 100% of the time, except in the case of the first initialization, we are not changing any of the variables in the Operator class. However the state does change.

For example, there can be an existing operator when we're initializing git gud in a sub-directory, and there won't be an operator available during the first initialization.

We have tried caching the operator, but this leads to issues with testing when we're using the same operator for the entire duration of the tests, so it's worthwhile to just grab a new operator each time.

Overall, the inconvenience of typing get_operator every time we need to perform a file operation is worth the ability to modify the directory and to provide a namespace for all the variables and methods we're using.

[benthayer]

Closing immediately because this is not an issue but is something we considered

[benthayer]

One way we could have changed things was to use this to get a list of all of methods in the operations class [ x for x in dir(Operations) if type(getattr(Operations, x)) is type(Operations.example_method)] We could then define globals, which could then be imported like so globals()[example_method_name] = getattr(Operations, example_method_name). The operations object would still exist and we could use it explicitly if we wanted.

We could also just leave all variables in the operations module, which provide its own namespace. To init Git Gud in a new directory, we would just change the necessary paths in the module instead of the class.

We could also continue using the operations object, but just for the variables. We would then define the methods outside of the class and use the class as needed, automatically instantiating it as needed.