Stdlib: add `deprecated` messages on `Test` (for `Test.Next`)

Motivation and Context

We need to give a deprecate message for those primitives in Test which are already available in Test.Next.

Description

This MR adds the tag [@deprecated] to functions that will be deprecated in future versions:

    File "../../test/contracts/increment_prefix.jsligo", line 24, characters 13-27:
     23 |   let initial_storage = 42;
     24 |   let orig = Test.originate(contract_of(IncDec), initial_storage, 0tez);
                       ^^^^^^^^^^^^^^
     25 |   Test.transfer_exn(orig.addr, Increment(), 1mutez);
    :
    Warning: deprecated value.
    In a future version, `Test` will be replaced by `Test.Next`, and using `Originate.contract` from `Test.Next` is encouraged for a smoother migration.

    File "../../test/contracts/increment_prefix.jsligo", line 25, characters 2-19:
     24 |   let orig = Test.originate(contract_of(IncDec), initial_storage, 0tez);
     25 |   Test.transfer_exn(orig.addr, Increment(), 1mutez);
            ^^^^^^^^^^^^^^^^^
     26 |   return assert(Test.get_storage(orig.addr) == initial_storage + 1);
    :
    Warning: deprecated value.
    In a future version, `Test` will be replaced by `Test.Next`, and using `Typed_address.transfer_exn` from `Test.Next` is encouraged for a smoother migration.

    File "../../test/contracts/increment_prefix.jsligo", line 26, characters 16-32:
     25 |   Test.transfer_exn(orig.addr, Increment(), 1mutez);
     26 |   return assert(Test.get_storage(orig.addr) == initial_storage + 1);
                          ^^^^^^^^^^^^^^^^
     27 | }) ();
    :
   Warning: deprecated value.
    In a future version, `Test` will be replaced by `Test.Next`, and using `Typed_address.get_storage` from `Test.Next` is encouraged for a smoother migration.

Component

• compiler
• website
• webide
• vscode-plugin
• debugger

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Performance improvement (non-breaking change that improves performance)
• None (change with no changelog)

Changelog

Checklist:

• If a new syntax has been introduced, put a message on slack ligo-lsp
• Changes follow the existing coding style (use dune @fmt to check).
• Tests for the changes have been added (for bug fixes / feature).
• Documentation has been updated.
• Changelog description has been added (if appropriate).
• Start titles under ## Changelog section with #### (if appropriate).
• There is no image or uploaded file in changelog
• Examples in changed behaviour have been added to the changelog (for breaking change / feature).