feat: configure global allocator by default

[austinabell]

• Removes need to configure global allocator and enables wee_alloc for wasm32 architecture
  • Can eject from this behaviour by using the custom-allocator feature

This is only a breaking change if the allocator is set up manually in the contract (not using near_sdk::setup_alloc!()) AND the custom-allocator feature is not set. This needs to only be attached to the 4.0 release discussed in #387

This progresses the goal of zero boilerplate. I also verified that the allocator is set up correctly in all allocator setup and feature usage combinations.

[matklad]

LGTM! In the future (next major version), I think we

• should make make wee_alloc an optional, default dependency
• use wee_alloc as a feaature name
• stop re-exporting wee_alloc.

[austinabell]

LGTM! In the future (next major version), I think we

• should make make wee_alloc an optional, default dependency
• use wee_alloc as a feaature name
• stop re-exporting wee_alloc.

I agree, given that breaking changes are coming in now, and without squashing it might be hard to cherry-pick the non-breaking changes, maybe this is a good time to make this change given that the next release would be a major one (afaik)?

Edit: actually re-reading this, seems weird if we were to have these two features. Maybe a better feature/name pattern is having default-allocator which enables wee_alloc and is enabled by default and removing the custom-allocator feature (as it would do nothing)

[willemneal]

Yay!

[austinabell]

Okay, I've decided to switch the feature to be wee_alloc rather than custom-allocator for the following reasons:

• This will be released with a major release so it's fine to remove the re-export and wee_alloc used when the feature is disabled
• Removes the need to maintain the custom-allocator feature in the future
  • It is a negative feature where functionality is removed, which goes against Rust's feature assumption that they are additive
  • Removes the need for two features handling the same piece of code (if feat: configure global allocator by default #429 (comment) is done after this comes in)
• All the same breaking conditions are the same (only is breaking if the allocator is set manually, and it will be more clear what has changed this way)
• Can deprecate the setup_alloc macro, to make it clear that it isn't needed and make sure the default features are not dropped

The negative is that if a developer has disabled default features on the SDK and uses the setup_alloc macro and misreads the deprecation, they could potentially remove the wasm allocator without noticing. I don't really think this is a problem we should set up the long-term features around though, and the confusion around using the two features is worse.