[doc] fix Move package tutorial

[sblackshear]

The package tutorial is currently broken, which is confusing some folks on Discord and in builder's groups. Let's take this opportunity to fix and simplify the tutorial:

• Use sui move new to create the package skeleton
• Fix sui move new to create a Move.toml that depends on the devnet branch + has a named alias for sui by default
• Fix unused imports in the example code
• Expand the example code and explain the different parts of the module

[damirka]

... (github bugged) ... see below

[damirka]

Absolutely love these changes! One thing I would add (I try to stick to this code style) -> putting accessors / getters up, so the overall structure of the module is:

- imports
- consts
- structs
- views
- public / entry functions
- private functions

[sblackshear]

Absolutely love these changes! One thing I would add (I try to stick to this code style) -> putting accessors / getters up, so the overall structure of the module is:

- imports
- consts
- structs
- views
- public / entry functions
- private functions

Like the ordering + will add this recommendation to the doc!

Question: where does the module initializer fit in here--in "private functions"? Putting most private functions at the end makes sense to me, but I do kind of like having the initializer come right after the type defs since it's often closely related to singleton objects like the Forge

[damirka]

Question: where does the module initializer fit in here--in "private functions"? Putting most private functions at the end makes sense to me, but I do kind of like having the initializer come right after the type defs since it's often closely related to singleton objects like the Forge

Whoops. Forgot about the init buddy. Funnily enough rarely do I have modules that use init() and are generic - which means they don't have custom type definitions except for witnesses and require getters. Don't have strong preference, but assume that what you're suggesting is the best option!