Usually LCD displays come in a plastic "cage" that has pins (more precisely, bumps - they are very short) on each corner of its back. The PCB has holes to fit in, but that's just to prevent the display from sliding horizontally on the board. The board is then attached someway (screws, etc.) against the case "top" which has a window for the display, a little smaller than it in each dimension, and that holds it in place. Usually there's no need for an adhesive or glue, which also makes repair easier; just the LCD ribbon is really mechanically attached to the board. But for hobby projects there's nothing that prevents you to do so.
There are other, less popular methods. Displaytech's "LCD Connection Methods" document has a few diagrams, but it's not possible to attach a file here in .pdf format. In a roundabout conversion method, it's now on E&R's imgur account here, sorry for the low quality.
Flicker is a result of too slow refresh. You need to refresh each segment at a few 100 Hz minimum. However, there are some tricks that can reduce apparent flicker while not actually doing faster refresh. The naive approach is to refresh the digits in order. But, if you alternate them a bit, the whole number will appear to flicker less. For example, do digits 1, 3, and 5, then come back and do digits 2, 4, and 6.
Without knowing the processor and seeing the source code, it's impossible to say whether the vendor is trying to string you along or the mess really needs to be re-written. Keep in mind that 99% of firmware engineers write horrible firmware. There could be hard coded constant all over the place that make assumptions about the clock frequency, the LED refresh rate, etc. With well written firmware, increasing the refresh rate assuming the processor has the necessary cycles already should be easy. With badly written firmware, it could be a lot more trouble than to ditch the mess and write it right.
How come the original designer didn't address the flicker? Perhaps the firmware is so badly architected that simply increasing it wasn't possible? If the flicker is that obvious, then why was the product ever created the way it is? That alone makes it likely the original designer made a mess. If he could have easily fixed it, he probably would have.
The really funny thing is now you're doing it again. You are going overseas because you want to keep costs down. Good design costs real money, but bad design costs much more. Even though you have been bitten by that, you have still not apparently learned it. With good design in the first place you wouldn't be in this position, and even if you were, it should be easy to change. There is no excuse for changing stored audio not being a simple operation.
How do you know if it's a bad idea or not to change the microcontroller and the circuit if you don't know what either are? Buying engineering strictly on price is the most expensive way to go.
Added in response to comments:
I don't remember where I heard about refreshing digits non-sequentially, but I have tried it and found it to help. I think it works for the same reason interlaced TV appeared to flicker at the field rate instead of the frame rate. For NTSC, the whole picture was redrawn at 30 Hz, but the apparent flicker was 60 Hz because of the interlacing refresh. You're not going to get 2:1 like that by interlacing digits, but it does help.
No, 60 Hz is not fast enough, not even close. 60 Hz is about where most people don't see flicker anymore for a square wave. Someone staring directly at a LED driven 50% of the time at 60 Hz may not see the flicker, but that's not the only way people perceive it. Unless you only have two digits, the LEDs will be on brighter for a smaller fraction of the time, which makes the flicker more apparent. The center of your retina is the slowest in responding. You will notice flicker more at the periphery of your vision. However the real objectionable part is when you move your eyes. Flicker is easily apparent at 60 Hz. You can't make the flicker invisible due to this phenomena, so the problem is to make it less annoying. 60 Hz is still quite annoying for most people. As I said, you want a few 100 Hz at least. If you have to pick a number, I'd start by trying to achieve at least 500 Hz.
As for getting good engineering, that's a whole topic on its own. There is nothing inherently wrong with going overseas. Competent people live in various places. The issue is first to recognize that bad design will cost a lot more than hiring a top engineer to do it right in the first place. Second, you have to realize that finding and vetting engineering talent takes some work. You're going to spend 1000s of $, probably 10s of 1000s of $. Treat it like other purchase decisions of that magnitude. Ask around, interview, get references and actually follow up on them.
As long as you're serious and the job is real, I'd say you have the right to expect around 2 hours of initial consultation before any committment is made. Keep in mind that goes both ways. Part of this time is for you to evaluate the engineer, but of course the engineer is evaluating you too. They are trying to decide whether this job fits in line with what they want to be doing, whether you are going to be a pain in the butt customer, etc. Either way, there should be plenty of time to get into the requirements and talk about initial impressions of what path the engineer will persue towards the solution. This should tell you a lot about how they think, how much they just implement whatever you told them versus drilling down and trying to get at the real problem and making sure that is solved, suggesting alternate solutions, etc.
None of this says the engineer can't be oversees, but it does make logistics and good evaluation difficult. If you have a couple of strong recommendations from people you trust, then that helps a lot. If you're logic is only that Bob in Boston wants $130/hour and is estimating 4 weeks while Naresh in Bangalore wants $35/hour and can do it in 2 weeks, you're headed for serious trouble.
Best Answer
While some display controllers cause flicker any time they are written, this particular controller shouldn't have that problem. I would guess you are having flicker because on each update you are writing parts of the display with one value and then rewriting them with another. To avoid flicker, don't do that. Figure out what the correct value should be for each pixel before you write it. If your display consists of various non-overlapping rectangles that could move around, and if you're presently erasing the whole screen and then drawing your rectangular objects, you may be able to improve both performance and appearance by only erasing regions where no objects are supposed to appear; depending upon the application, you may be able to improve performance further by only erasing regions where objects used to exist but have just "disappeared".
Addendum Looking at the supplied picture, what is happening is that the display pixels are being written to in one direction (I would guess top-to-bottom), and the display is scanning in another direction (I would guess left to right). This has the effect that the amount of screen data that has been written when the hardware starts scanning a frame is much less than the amount which has been written by the time the hardware scan reaches the right edge. Consequently, the lines which are drawn near the right edge of the screen will have more data drawn on them than the lines near the left.
If you draw data onto the screen in a direction perpendicular to the display scan, you will get the type of diagonal lines you observe here. If you draw data linearly in a direction which is parallel to the display scan at a rate which is slower than the scan rate, there will be an observable "tear" each time the display scan overtakes your drawing. If you draw data at a rate which is faster than the scan rate, and do so in a fashion which is synchronized with the display scan, you can avoid having any kind of display artifacting, but I have not observed any color LCDs (and very few monochrome ones) with a CPU interface which would allow a connected CPU to synchronize updates with the display scanning. That's too bad, because such an ability would allow cleaner display updates than are possible otherwise. A nice easy technique which was used in many arcade games designed by Eugene Jarvis in the early 1980's was to have the display scanning process interrupt the processor when the scan hits the middle of the screen and again when it hits the bottom. When the scan hits the middle of the screen, everything above the current scan line may be safely updated without flicker provided the updates happen before the scan reaches the bottom. When the scan hits the bottom, everything below the middle may be updated without flicker, provided the updates happen before the scan reaches the middle. It looks as though this controller chip does provide a function to output a pulse when the scan reaches a specified point ("tearing effect line") but I would conjecture that the output is probably not wired to a pin on the display's connector.
I don't know exactly what you're trying to display, but I would suggest that you either work to ensure that any time a pixel is written at all it's written with its "final" color or, failing that, minimize the amount of time between the first and last write to each pixel. For example, if you don't have enough memory to buffer anything externally, you might clear 32 rows of pixels, and then draw everything which should appear in those 32 rows, then clear the next 32 rows, draw everything which should appear there, etc.
Addendum 2
If you have a 16-bit data bus which connects to both the display and the SRAM, and if you have at least one address bit coming out of the CPU that doesn't connect to the RAM (e.g. A18), a useful technique would be to connect that extra address bit with some logic so that any read or write access will be handled by the SRAM as normal, but if that bit is "1" it will also hit the "write data" strobe on the display. If you do that, reading a word of RAM at its normal address will behave as it normally would, but adding 0x00040000 (assuming you use A18) to the address and then performing the read would cause that word of data to be sent directly from RAM to the display (the processor would also read the data, but it wouldn't have to do anything with it). If you don't have an extra address bit available, there are other techniques you could use instead, but I'd have to know more about your hardware to know what to recommend.