Inconsistent logging of job name/id when adding/running/removing jobs

Hi, thanks for the great work you've done here!

**Describe the bug**
Depending on if a job has an ID, a name, neither or both, the log messages aren't always straightforward to link the "adding"/"start"/"finished" and removal phases in the log. The workaround I've adopted is just having the name and ID equal to prevent later confusion. It would possibly make more sense to also log the job ID each time vs. the name / function name (?).

Using examples from the reproducing section.

A job with just an ID and no name. The "add", "start", "finished" stages all use the function name while the "removed job" uses just ID.

```
>>> _ = scheduler.add_job(func_job_with_an_id_and_no_name, id="test-job-id-only")
INFO:Scheduler:Added job "func_job_with_an_id_and_no_name" to job store "default"
INFO:apscheduler.executors.default:Running job "func_job_with_an_id_and_no_name (trigger: date[2021-02-02 17:08:35 UTC], next run at: 2021-02-02 17:08:35 UTC)" (scheduled at 2021-02-02 17:08:35.098253+00:00)
INFO:root:This Job was scheduled with an ID and without a Name
INFO:apscheduler.executors.default:Job "func_job_with_an_id_and_no_name (trigger: date[2021-02-02 17:08:35 UTC], next run at: 2021-02-02 17:08:35 UTC)" executed successfully
INFO:Scheduler:Removed job test-job-id-only
```

Same is seen when just the `name` is given - the name is referenced until the removal which uses the ID.

```
>>> _ = scheduler.add_job(func_job_with_no_id_and_a_name, name="test-job-name-only")
INFO:Scheduler:Added job "test-job-name-only" to job store "default"
INFO:apscheduler.executors.default:Running job "test-job-name-only (trigger: date[2021-02-02 17:08:35 UTC], next run at: 2021-02-02 17:08:35 UTC)" (scheduled at 2021-02-02 17:08:35.100541+00:00)
INFO:root:This Job was scheduled without an ID and with a Name
INFO:apscheduler.executors.default:Job "test-job-name-only (trigger: date[2021-02-02 17:08:35 UTC], next run at: 2021-02-02 17:08:35 UTC)" executed successfully
INFO:Scheduler:Removed job d6588cc2c6c0462d97527232377e66e0
```

**To Reproduce**

Any scheduler/executor/jobstore combo should do, but for the sake of this test:

```
import logging
from apscheduler.schedulers.background import BackgroundScheduler

def func_job_with_no_id_and_no_name():
logging.getLogger().info("This Job was scheduled without an ID and without a Name")

def func_job_with_an_id_and_no_name():
logging.getLogger().info("This Job was scheduled with an ID and without a Name")

def func_job_with_no_id_and_a_name():
logging.getLogger().info("This Job was scheduled without an ID and with a Name")

def func_job_with_an_id_and_a_name():
logging.getLogger().info("This Job was scheduled with an ID and with a Name")

logging.basicConfig(level=logging.INFO) # Set the logging to Debug

logger = logging.getLogger("Scheduler")
scheduler_config = {
"apscheduler.timezone": "UTC",
}
scheduler = BackgroundScheduler(scheduler_config, logger=logger)
scheduler.start()

scheduler.add_job(func_job_with_no_id_and_no_name)

scheduler.add_job(func_job_with_an_id_and_no_name, id="test-job-id-only")

scheduler.add_job(func_job_with_no_id_and_a_name, name="test-job-name-only")

scheduler.add_job(func_job_with_an_id_and_a_name, id="test-job-id", name="test-job-name")
```

**Expected behavior**

Using the function name as the default identifier is part of the issue as often this is not unique and you'll have multiple jobs using the same function.

Would it make more sense to always refer to the ID in add/start/finished/remove job stages. Provide the link to name/function in the first job "add" message.

eg.

```
INFO:Scheduler:Added job "func_job_with_no_id_and_no_name" (0066c44beb0341c3b336efcf88f22f52) to job store "default"
```

```
INFO:Scheduler:Added job "test-job-name-only" (d6588cc2c6c0462d97527232377e66e0) to job store "default"
```

and then refer to the ID for the later messages?

===

The easy fix is probably just to correct the "Removed job" message so it's consistent.

**Additional context**
Add any other context about the problem here.