fix unused variable warning on new projects

[mikemaccana]

Running anchor init and then anchor build always returns:

warning: unused variable: `ctx`
 --> programs/deleteme/src/lib.rs:9:23
  |
9 |     pub fn initialize(ctx: Context<Initialize>) -> Result<()> {
  |                       ^^^ help: if this is intentional, prefix it with an underscore: `_ctx`
  |
  = note: `#[warn(unused_variables)]` on by default

warning: `deleteme` (lib) generated 1 warning (run `cargo fix --lib -p deleteme` to apply 1 suggestion)

This is a bit of an unnecessary distraction. This PR silences the warning by simply logging the program ID in the default function handler.

Additionally, context is spelt context to be consistent with the rest of Anchor. Right now prelude, program, initialize, handler, wallet, are all full words without contractions but ctx is contracted, and when discussing Anchor we have to consistently remind people of this by saying "context, spelled 'see tee ecks'". It's a change, but people that already know anchor should easily understand that context is ctx and people new to anchor can save some unnecessary confusion.

[vercel]

@mikemaccana is attempting to deploy a commit to the coral-xyz Team on Vercel.

A member of the Team first needs to authorize it.

[acheroncrypto]

Additionally, context is spelt context to be consistent with the rest of Anchor. Right now prelude, program, initialize, handler, wallet, are all full words without contractions but ctx is contracted, and when discussing Anchor we have to consistently remind people of this by saying "context, spelled 'see tee ecks'". It's a change, but people that already know anchor should easily understand that context is ctx and people new to anchor can save some unnecessary confusion.

We could change it if there weren't a billion examples using ctx, it's too engrained in the framework to change this, and doesn't bring enough benefits as I've also mentioned in #2883.

In #2883 (comment), you mentioned:

Consider the size of each audience:

• people that have previously written a program using Anchor
• people that will potentially write a program using Anchor in future

I imagine the latter is at least one, perhaps two orders of magnitude larger.

This is one of those things that works great in theory, but what really happens is that those in the larger pie, who don't yet know Anchor, follow examples and tutorials written by the earlier crowd, and chaos emerges. I don't think it's beneficial to make naming changes like this.

[mikemaccana]

Got It,ctx it is. Updated.

[acheroncrypto]

Thanks!