fix PoW and other functions not working with USE_TORCH=0 despite torch being available

[mjurbanski-reef]

Bug

This fixes problem that after #1904 uses wanting PoW and other torch-using functionality were forced to use USE_TORCH=1 which also forced the legacy torch-based interface.

Description of the Change

• users can now use torch-requiring code despite using new interface - this should prevent users being even more reluctant to upgrade just because they use few functions that require torch
• the default value in example.env is now USE_TORCH=0, so users don't accidentally run legacy interface - we want old users to move to new one as soon as it is viable AND none of the new users should accidentally run legacy interface
• fixed recursion error in lazy torch loader class which happend when requesting nonexistent attribute
• refactored the lazy torch loader and added tests for it
• added legacy_torch_api_compat for an easier way of maintaining two interfaces, but only used it in limited fashion for now

Alternate Designs

as written above, no

Possible Drawbacks

No real drawbacks that Im aware of.

Verification Process

Unit tests added and manual tests.

Release Notes

None, this fixes regression introduced by #1904 that was yet to be released.

[mjurbanski-reef]

IMO this approach of just having one implementation of a function and then translating only input and output will be much easier to maintain, but I leave it to others if they want to use it in more places or if they want to keep using if use_torch() all over the place

[mjurbanski-reef]

@thewhaleking as author of #1904 you maybe interested in this PR

@gus-opentensor this probably should also land in v7, as it will make users less reluctant to switch to numpy interface

[thewhaleking]

This overall looks good to me.

[thewhaleking]

I really like this approach. I would recommend updating this line, as it reads as the opposite of what it's saying. Other than that, this seems great.