Added Build and Deploy section for vanilla bash approach

[rimutaka]

Our build and deploy instructions are focused on cargo lambda which hides a lot of complexity, but I feel like we should provide an explanation of the fundamentals needed to build and deploy Rust lambdas.

This change should help with understanding the basics and reduce issues like #878 and a bunch of others related to AL2/GLIBC.

I added an overview section and made a few tweaks in other parts to remove repetition.
There is still some duplication with the existing content. I'd like to address that in a separate PR.

Feel free to shoot this down. No hard feelings at all.
I can always write a blog post explaining it if you think it does not belong in the README.

Changes:

• added an overview how to build and deploy without using cargo lambda
• fixed a typo
• removed a duplicated statement
• added a link

🔏 By submitting this pull request

• I confirm that I've ran cargo +nightly fmt.
• I confirm that I've ran cargo clippy --fix.
• I confirm that I've made a best effort attempt to update all relevant documentation.
• I confirm that my contribution is made under the terms of the Apache 2.0 license.

[calavera]

I do not agree with these changes. One of the reasons why this runtime has grown in user base is because we've made it really easy to build and deploy with Cargo Lambda. Putting bash as the first option adds complexity. Many new users won't read pass that, and they will be discourage to use this runtime.

[rimutaka]

@calavera , David, sorry, I'm not sure what change you requested. Shall I move the pure bash part to the back somewhere?

[calavera]

This change should help with understanding the basics and reduce issues like #878 and a bunch of others related to AL2/GLIBC.

What are the other related AL2/GLIBC issues? so far, the only problem I've seen people bumping into is trying to run their code against an older GLIBC version. If the goal is helping people troubleshoot those issues, I don't think these changes will help, as they don't explain the problem or the solution. It might be more useful to have a "troubleshooting" section where we explain those kind of issues directly.

I'm ok if you want to compliment some other sections below with more details about creating things manually, but I don't want it as the first option as it was the largest pain point that people had when I started maintaining this project two years ago.

[rimutaka]

Not sure this is needed.