Unable to build an app in a directory that has a tasks.cr file

Nobody has claimed this yet.

Right now we assume that if there's a `tasks.cr` file, then you must be inside a Lucky app directory

https://github.com/luckyframework/lucky_cli/blob/ccaa571765582086d437efe0da4f439a19929d64/src/lucky.cr#L14

Then when you run `lucky -h` you'll get different output depending... This is helpful to avoid an issue where you generate a Lucky app inside of a Lucky app accidentally...

However, [Breeze](https://github.com/luckyframework/breeze) has a `tasks.cr` file, and is not a Lucky app... so when trying to run the integration specs https://github.com/luckyframework/breeze/blob/674b438fde9da5686a49c9e35290365e45bf9f85/spec/integration_spec.cr#L11 it attempts to build a Lucky app inside of the root of the breeze directory, and instead of just saying "nope", you get

```
❯ lucky init.custom test-project
Showing last frame. Use --error-trace for full trace.

In lib/avram/src/avram/database.cr:156:5

156 | settings.credentials
^-------
Error: undefined local variable or method 'settings' for Avram::Database+.class
```

which really makes no sense... Moving this to a `tmp/` dir "solves" it...

I do like having the safety of not accidentally generating an app inside an existing app, but I guess is it really necessary vs what we lose not being able to?

Start at src/lucky.cr#L14 and reproduce the behavior from Breeze's spec/integration_spec.cr#L11 with `lucky init.custom test-project` in a directory containing tasks.cr. Determine how the CLI distinguishes a Lucky app from another Crystal project, then verify that non-Lucky projects no longer produce the misleading Avram error while the existing safety check remains meaningful.

Written by the indexing model from the issue text.