Consistently define SurrealException base class (once)

[alexander-beedie]

What is the motivation?

Ensuring that there aren't two different/competing SurrealException definitions. The two definitions have the same name but are different objects, which can lead to various issues/gremlins.

Type of Change

• 🔧 Bug fix (non-breaking change which fixes an issue)
• 🥂 Improvement (non-breaking change which improves an existing feature)

What does this change do?

Establishes a single location for (and definition of) the core Surreal exception classes.
This ensures that there is only one SurrealException base class.

What is your testing strategy?

Unit tests.

Have you read the [Contributing Guidelines]?

• I have read the [Contributing Guidelines]

[maxwellflitton]

Hey @alexander-beedie thanks for the pull request I appreciate it. However, I must note that this is focused on the directory of python_package/surrealdb/. I just want to make sure that you know that this directory is deprecated. I should have written some documentation to make this clear, the main focus for us now is in the surrealdb directory in the root where we are writing a lot of the functionality in rust and use pyo3 bindings

[alexander-beedie]

Hey @alexander-beedie thanks for the pull request I appreciate it. However, I must note that this is focused on the directory of python_package/surrealdb/. I just want to make sure that you know that this directory is deprecated. I should have written some documentation to make this clear, the main focus for us now is in the surrealdb directory in the root where we are writing a lot of the functionality in rust and use pyo3 bindings

Not to worry, will pay more attention to the current/primary directory, hah! Will close it out; let's not confuse things by making it look like this part of the codebase is active if it isn't. Looks like #92 will tidy things up ;)