🚀 Feature: Refactor & Rename Dart Server Api

[natgross]

🔖 Feature description

Rename the Dart Server client to something like 'Dart Superuser' client, also refactoring (renaming) the classes to prefix (or suffix) the common class names with 'su', like SUAccount or AccountSu (or whatever).

🎤 Pitch

For a newbie or even a pro, when seeing the many aw client SDK's, it is easy to assume that a 'server' client is for my (http or whatever Dart) server that is also a client to the Appwrite server. Hence, when certain functions are restricted from the normal client, but do exist in the server client, I need to decide if it's worth for me to spin up a http server just for this or that feature.
For example, creating collections from the aw client, seeing that a 'server' client can do it, doesn't help me too much. (Because I incorrectly assumed that it meant an http server of my own.)
Now, this server (superuser) client IS indeed the right way to go, but the naming clashes is still a problem.
Hence, this feature request.

👀 Have you spent some time to check if this issue has been raised before?

• I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

• I have read the Code of Conduct

[stnguyen90]

Thank you for raising this issue! 🙏

A great deal of our documentation differentiates between Client and Server SDKs and APIs (eg. SDKs and Databases API). It's also important for us to emphasize the Server SDKs/APIs are to be used server side only and not in any client application because doing so poses a security risk. Is there any place where we should work to better explain the difference?

For the Appwrite Dart SDK, we emphasize in the readme:

This is the Dart SDK for integrating with Appwrite from your Dart server-side code. If you're looking for the Flutter SDK you should check appwrite/sdk-for-flutter

What can we do to make that clearer?

[natgross]

About the security risk. The folks using appwrite are pros and let them decide on the risk. For example, logging into many systems as 'superuser' or 'admin' is clearly a risk. After fair warning, the supervisor is on his own. As your own docs point out at https://appwrite.io/docs/getting-started-for-server.
What I am saying is simple, I agree, BUT, the api should be called superuser-api, to clarify what it is, and to bring out YOUR point better. THEN, you can say, 'folks, it's best to use this api from server side'. Or use at your own risk.
Professionals know how to protect themselves and would use the api disparagingly from a client, when super needed.
You don't want to limit your user base.
Anyhow, I am not here to argue, just thought it was a good idea.